Hi,
Ross J. Reedstrom:
> People keep claiming that applications that are essentially "read-only"
> don't need transactions. I'll agree in the limit, that truly read only
> databases don't, but I think a lot of people might be surprised at how
> little writing you need before you get into trouble.
> [ Mozilla buchtracking example ]
> How many writer's does it take for this to happen? One. I'd call that
> an "essentially read-only" system. A note, this is not a made up,
> theoretical example. We're talking real world here.
>
Right. But that's not about transactions; that's about concurrent read
and write access to a table.
People using MySQL in real-world situations usually solve this with one
read/write database for "normal" work, and another one for the
long-running multi-record "let's list every bug in the system" queries.
The update from one to the other is set to low-priority so that it won't
lock out any queries (with a timeout).
Mind you: I'm not saying this is ideal. A system with concurrent
read/write access would be better. But it has the benefit of giving
you a replicated database which you can fall back to, if the primary
system is down for whatever reason.
Besides, the MySQL people are currently busy integrating Berkeley DB
into their code. Voila, instant read/write concurrency, and instant
transactions. Well, almost. ;-)
--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
Acrophobes go down with little persuasion.
