shells and bells

[Mike Bilow]

On 2000-05-03 at 20:17 -0400, Niall Kavanagh wrote:

> NOTE: I'm typing this from a wireless keyboard that's about 10"x4", so
> forgive glaring typos. ;)

I use a Tohiba Libretto myself, although not right at the moment.

> Mysql uses a locking method they call "atomic operations" (I'm not
> sure if this is a mysql-ism?) which results in
> a database server which is 2-4 times faster than a finely tuned
> transactional setup.
> 
> Instead of using commit/rollback to ensure integritu=y, mysql relies on
> simple checks before updates, and tools that check the database for
> inconsistancies. This combined with an update log means you can fix any
> problems quite easily.
> 
> >From the mysql manual, a snippet you may find interesting:
> 
> "Lastly, in situations where integrity is of highest importance,
>    MySQL's current features allow for transaction-level or better
>    reliability and integrity. If you lock tables with LOCK TABLES, all
>    updates will stall until any integrity checks are made. If you only
>    obtain a read lock (as opposed to a write lock), then reads and
>    inserts are still allowed to happen. The new inserted records will not
>    be seen by any of the clients that have a READ lock until they
>    relaease their read locks. With INSERT DELAYED you can queue inserts
>    into a local queue, until the locks are released, without having to
>    have the client wait for the insert to complete."

Let me go out on a limb here: this operating paradigm is borderline
insane, like saying that cars would be faster without brakes.  In a sense
this is true, but it is making a virtue out of a defect, which is greatly
disingenuous.  The problem is that, since MySQL has no notion of a
transactional queue, there is no way for EACH updater to do these pseudo
transactions.  Each updater who wants to modify the database must assert a
read lock against the whole table, and possibly against multiple tables,
effectively shutting down the whole database.  What this paragraph above
says is that ANY updater can stop ALL OTHER updaters from having their
changes committed, but that leads to an undefined situation.

It also does not help that MySQL implements this bizarre model using
non-standard SQL syntax extensions, such as "INSERT DELAYED."  ANSI SQL
defines perfectly solid syntax for managing transactions and these are
respected and understood by a wide range to tools and languages, from
C/C++ ODBC to Perl libraries to Java JDBC.  Some languages, particularly
Java, themselves have transactional extensions (JTA over JDBC) which can
only interoperate with a database server which does standard transactions.

> YMMV. I for one am very pleased with mysql.

This is because it is a big index card server, not a real database, but it
works pefectly well if what you need is an index card server.

> I really don't see anything damning about mysql besides the
> license. Just because it uses a different paradigm for integrity doesn't
> mean it's inferior. It may not suit your needs, but based on the
> arguements you're presenting I don't see why not. Data gets screwed up on
> transactional setups too. No system is perfect. My main point is "try 'em
> both and decide for yourself based on the facts." Lucky for the original
> poster we've got a lot of knowledgable folks in this group with a lot of
> facts. ;)

Transaction support has nothing to do with data getting screwed up.  
Rather, it has to do with who makes the decisions about the real-world
significance and correspondence of the data.  The client is the side which
imparts human meaning to the data, and it is where the locus of decision
significance should reside.  If a telephone clerk is running an order
entry system and the customer changes their mind, this should not require
a database operation beyond a simple rollback to cancel the order.  At the
same time, the order entry system should not allow two different clerks to
decrement the same inventory item by selling it to two differnt customers,
at least not without them knowing about it.  In fact, row-level locking
and transaction support are part of any basic database system which
involves concurrent updates by different arbitrarily sequenced parties.

> Database servers are like sexual positions; having someone explain them to
> you is no fun. You have to try 'em all out yourself and find out which
> one(s) work(s) for you. Some people like fast, some like traditional, and
> some are best left undiscussed (MS SQL SERVER 6.5 BABE!).

I suppose this may be the case, but there are probably a wide selection of
sexual positions which one could reasonably infer would not be much fun
without actually trying them out, such as hanging by a rope and dangling
several hundred feet above asphalt pavement with a TV news crew below.

-- Mike


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).