Comments on: Resolving transaction concurrency issues in a PHP+MySQL multi-user environment

By: ardamis

ardamis — Sat, 31 Jul 2010 02:50:49 +0000

I would think that if only one user can access any given record, then there would be less opportunity for problems to arise. But there is still a possibility that data could be lost. For example, a user could access the same record from two separate browsers (log in from home, leave that page up, and then log in later from work) and cause data loss in the same way as two different users accessing a single record.

In my opinion, a responsible developer will work to eliminate any possibility of data loss, however unlikely.

By: David DelMonte

David DelMonte — Sat, 31 Jul 2010 02:00:58 +0000

Would you all recommend the same solution if every user’s data was their own. I am building an app which people can use off of my site, but they each have their own data. Do I replicate the database or follow the examples here, or do something different.. I would appreciate your wisdom..

By: Jon di Elos

Jon di Elos — Tue, 20 Apr 2010 19:02:52 +0000

Why not relly on MySQL innoDB concurrency model? Is there any problem requirement which makes innodb inpractical in this case? Did I miss something?

Regards,
Jon di Leos

By: ardamis

ardamis — Mon, 01 Jun 2009 20:09:46 +0000

A hash is a great idea, and in one implementation, it could eliminate the need for each record to contain the timestamp data. However, as pointed out in another comment, attempting to modify the record using an UPDATE that looks for the timestamp serves to check that the record can be modified at the same instant it would be changed.

I’m not at all familiar with the risks involved with thread switching, but it seems to me that there still exists the potential for data loss in the time it takes the server to calculate the MD5 sum and then send the data to the database.

I’ll certainly consider using it the next time this issue comes up, though.

By: Steve

Steve — Mon, 01 Jun 2009 19:27:07 +0000

I prefer to use a hash of the original record. When user A retrieves the record for editing, I generate an MD5 hash of the record data that is included as a hidden field in the form. When the user tries to write the record, I can determine whether the record was changed by comparing the MD5 hash. That eliminates the need to manage the timestamps.

By: Tom Christopherson

Tom Christopherson — Fri, 29 May 2009 22:57:36 +0000

Thanks for the write up… i’ve been wrestling with the same design issue for some time now and your explaination is the best I’ve seen yet as a possible solution.

By: Tony

Tony — Fri, 26 Sep 2008 11:41:16 +0000

Pretty cool solution. To add to that, it works great when process collision is greater than the granularity of the MySql timestamp which is per second. ie, no 2 process will do a read/write within 1 second.

To get around this, you can store the time as a bigint which can handle milliseconds. Unless you have some serious hardware, I don’t think collision granularity would go smaller than milliseconds.

Also instead of re-reading the timestamp before B saves, B should try to UPDATE row WHERE “opened timestamp” = “last modified timestamp”. Otherwise the CPU could potentially decide to switch threads on you right after you’ve done the second read, and do the entire read-write of A in that time.

By: ardamis

ardamis — Sat, 28 Jun 2008 03:40:51 +0000

That’s a very interesting PowerPoint presentation, thanks for linking it. And I’m happy to see that we both arrived at the same solution. I hope it serves you well.

By: jlaguna

jlaguna — Tue, 13 May 2008 06:41:13 +0000

Very good explanation, but I did found another source of information including the same idea:

http://www.cs.uta.fi/wo/slides/lecture%205.ppt