Re: Alternative MySQL PEAR DB sequence behavior
| From: | jimw@php.net | Date: | Tue, 24 Jul 2001 21:09:41 +0000 |
| Subject: | Re: Alternative MySQL PEAR DB sequence behavior | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-1031@lists.php.net to get a copy of this message | ||
Stig S. Bakken <Stig.Bakken@fast.no> wrote:
> Hm, right now all concurrency.php does is to check whether nextId
> returns an error. The race condition occurs if the "UPDATE *_seq SET
> id=LAST_INSERT_ID(id+1)" statement is not atomic, so that mysqld reads
> the current value of the table in request 1, reads the current value is
> request 2, and then both update the sequence with the same value, and
> both requests think they have gotten unique ids.
mysql guarantees that it is atomic. (single statements are always
atomic in mysql, as i understand it.)
and while i'm dipping into the thread, am i the only one who wishes
that PEAR::DB had an (additional?) interface that mapped more directly
to how mysql can handle sequences, and perhaps something that would
provide a generic interface for the functionality you get with mysql's
LIMIT?
jim