Re: Alternative MySQL PEAR DB sequence behavior

"Tomas V.V.Cox" wrote: > > "Stig S. Bakken" wrote: > > > > > > > > In my tests I a good combination of both params was: ./launch.sh 100 100 > > > (grater values may eat your resources, be careful). > > > > > > I know that it won't launch real simultaneous request, but seems to be > > > near it (a better sync system is welcome :), also it doesn't provide a > > > method to analyze the data. > > > > 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. > > My idea was to catch the output of the script and search for repeated > and non-consecutive values. My fear wasn't with UPDATE, was more with > the lock system and delete. I have the idea of using shared memory to > better syncronize processes. I know that probably this stuff won't serve > too much, but ... > I write a new sync mechanism via semaphores (needs PHP with '-enable-sysvsem' compiled in) and could launch near 60 processes in the same second and yeah my machine get stoned for a minute or so :). The stability and the speed of mysql/php/pear_db was quite impresive for me. Attached are the new scripts. Tomas V.V.Cox