Josh Whiting wrote: > SO, does anyone have some code that uses MySQL to replace PHP's native > session storage that also correctly handles this concurrency problem? Create your MySQL session tables using ENGINE=innoDB (in older MySQL, use TYPE=innoDB) http://mysql.com can tell you lots more about innoDB Then just wrap the contents of each function from the books in a BEGIN query to make them be transactions... Err, no, I mean, start the transaction in the one function and COMMIT in the save function. That should take care of all the concurrency issues, I think. > Folks using database sessions who do not deal with this scenario be > warned! I'm surprised so much bad code is going around for this task... Well, I don't use frames, or iFrames or any of that crap. And web surfer users have been conditioned by really bad shopping carts to not hit "Submit" twice :-) I guess I'm just saying that in the real world, the race condition for a single user/session just doesn't occur that often, and when it does, the user generally recognizes the problem/error and accepts that they caused it by being impatient or running two windows at once or whatever they did that made it happen. That doesn't make it Right, but it does make it Practical. Note that innoDB will have some performance differences from myIsam: myIsam is better/faster for all SELECT and INSERT applications with little or no UPDATE/DELETE. This is because it's been optimized like crazy over a long period of time by the MySQL folks, but it has to lock the whole damn table on UPDATE/DELETE (but not INSERT) in order to preserve integrity. It's also less susceptible to corruption on power loss, due to the way the optimization and INSERT work. innoDB will win if you have much UPDATE/DELETE because it does row-level locking and provides transaction support. Get a UPS if you want to avoid corruption on power loss. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
