Question

I have done extensive research about MySQL transactions via the PHP PDO interface. I am still a little fuzzy about the actual background workings of the transaction methods. Specifically, I need to know if there is any reason that I should want to prevent all my queries (SELECTs included) inside a transaction spanning from the beginning of the script to the end? Of course, handling any error in the transaction and rolling them back if need be.

I want to know if there is any locking going on during a transaction and if so, is it row level locking because it is InnoDB?

Answer 1

Don’t do that.

The reason for this is that transactions take advantage of MVCC a mechanism by which every piece of data updated is in fact not update-in-place but merely inserted in somewhere else.

MVCC implies allocating memory and or storage space to accumulate and operate all of the changes you send it without committing them to disk until you issue a COMMIT.

That means that while your entire script runs all changes are stored until the script ends. And all of the records that you try and change during the transaction are marked as “work in progress” so that other processes/threads can know that this data will soon be invalidated.

Having certain pieces of data marked as “work in progress” for the entire length of the script means that any other concurrent update will see the flag and say “i have to wait until this finishes so I’ll get the most recent data”.

This includes SELECTS depending on isolation levels. Selecting stuff that is marked as “work in progress” may not be what you want because some tables that you may want to join may contain already updated data while other tables are not updated yet resulting in a dirty read.

Transactionality and atomicity of operations is desirable but costly. Use it where it’s needed. Yes that means more work for you to figure out where race conditions can happen and even if race conditions occur you have to make the decision if they are really critical or is “some” data loss/mix acceptable.

Would you like your logs and visit counters and other statistics to drag down the speed of your entire site? Or is the quality of that information sacrificable for speed (as long as it’s not an analytics suit you can afford the occasional collision).

Would you like a seat reservation application to miss-fire and allow more users to grab a seat even after the seat cout was 0? of course not – here you want to leverage transactions and isolation levels to ensure that never happens.