Question

Is it possible, in my PHP 5.4.0 application (IIS, FastCGI, Non thread safe) for two people to update the same table in the database by running the same code at exactly the same time and inadvertently mess up each other’s data?

The reason I ask is because I see the occasional unexplained data glitch, and in the most recent case I found that another customer updated the same table at exactly the same time.

And part two of my question is if this is indeed happening, how do I prevent it?

Answer 1

They can’t “mess up each others data” because of non-thread safe PHP, no, unless you’re readying/writing Apache settings (e.g. with SetLocale) or you’ve programmed it to update shared information simultanously (e.g. flat files, as Amadam says).

Most normal processes such as MySQL, reading GET parameters etc will not be affected.

So unless your problem is with locales, it’ll be your code, not the thread settings.

If it’s with SetLocale, then transactions or other methods won’t make any difference. Anyhting else you can program round.

---

You can mess up data if you’ve not programmed for concurrent actions – this can happen in thread safe and non-thread safe. Remember that even in “thread safe” you can have concurrent threads being processed with different speed and orders.

Here is a dangerous example:

• Statement a) Read a table to get next update value
• Statement b) Write to table using previous value
• Statement c) Update “next update” table for next user.

The statements could be processed by “User 1” running all, followed by “User 2” (ideal, and how you programmed it). But equally so, “User 1” runs “a” and “b”, followed by “User 2” running all, then “User 1” running “c” – in this case, “User 2” will overwrite what “User 1” wrote.

(To repeat, this is NOTHING to do with “non-thread safe” in PHP.)

How to get around this latter issue:

1. Transactions MAY help you; they won’t actually help with the example above unless you use the “WITH CONSISTENT SNAPSHOT” option as all they do is delay the commit, and you’ve read the value too early in statement “a”.
2. Table locks allow you to prevent users reading or writing to a table, so in the example above, lock the “update” table first, run the transations then release the lock. This forces the second user to wait until “User 1” has completed the lot before it reads the number.
3. Use the capabilities of mySQL including “AUTO INCREMENT” primary keys, or codes such as “INSERT INTO… ON DUPLICATE KEY” or “REPLACE”.

The third option is the best, if you can. Table locks can get messy and transactions my not fix your issues.