Re: Alternative MySQL PEAR DB sequence behavior

jimw@php.net wrote: > > 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? If you're doing database specific stuff anyway, why not use $dbh->connection (we can add a method for retrieving it, for future compatibility) and mysql_insert_id()? As for LIMIT, I think we should add that. It can be emulated in "compatible mode" for others, too. - Stig