On Tue, May 23, 2000 at 12:36:16PM +0800, Michael Robinson wrote:
> "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> >On Mon, May 22, 2000 at 03:46:39PM +0800, Michael Robinson wrote:
> >> MySQL is extremely well suited for it: the data is essentially "read-only"
> >> so transactions, locking, etc., are not an issue,
> >
> >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.
>
> Very true. However, if you can guarantee that there is only ever one
> writer (e.g., a batch process), and you don't mind the occasional dirty
> read, you don't need any locking at all.
Right - my whole diatribe was actually about locking. And the case you
describe is what I meant by "in the limit, [a] truly read only database"
If all your writing is planned, controlled, batch updates, fine.
But my point stands: you only need _one_ ad hoc writer to potentially
get you into trouble, with all the messiness of lock contention, etc.
The work arounds mozilla.org were looking at to fix this problem
involve keeping multiple databases and syncing periodically, or lower
the priority of INSERTS (!): they looked like treating the symptom,
rather that addressing the problem, to me.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
