Posted by Richard Lynch on 03/08/05 20:38

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

[Back to original message]