Question

Quick question/clarification required here. I have a DB table that will quite possibly have simultaneous updates to a record. I am using Zend Framework for the application, and I have read about two directions to go to avoid this, first being table locking (LOCK TABLES test WRITE) or something like that, will go back and re-read how to do it exactly if that is the best solution. The second being transactions: $db->beginTransaction(); … $db->commit();

Now ‘assuming’ I am using a transactional storage engine such as InnoDB, transactions seem like the more common solution. However does that avoid the following scenario:

User A is on a webpage -> submits data -> begin transaction -> read row -> calculate new value -> update row -> save -> commit

User B is on the same webpage at the same time and submits data at the same time, now lets just say it is almost simultaneous (User B calls the update function at a point between begin transaction and commit for User A’s transaction) User B relies on the committed data from User A’s transaction before it can achieve the accurate calculation for updating the record.

IE:

Opening value in database row : 5 User A submits a value of 5. (begin
transaction -> read value (5) -> add submitted value (5+5=10) -> write
the updated value -> save -> commit)

User B submits the value of 7. I need to make sure that the value of
User B’s transaction read is 10, and not 5 (if the update isn’t done
before read).

I know this is a long winded explanation, I apologize, I am not exactly sure of the correct terminology to simplify the question.

Thanks

Answer 1

transactions doesn’t ensure locking. The whole block in transaction is treated as atomic update to db (if anything fails in between all previous changes of this block are rollback). So, two transactions running in parallel can update same row.

You need to use both.

Transaction do
 row.lock
 update row
end

see, if row level locking can make it easier for u.