Subject Re: [firebird-support] Transactions isolation levels and collisions
Author Aldo Caruso


    thank you very much for your answer.


El 01/03/17 a las 11:44, Ann Harrison aharrison@... [firebird-support] escribió:

On Mar 1, 2017, at 9:53 AM, Aldo Caruso wrote:


  Thanks for your detailed answer.

    But this leads me to the following question: If snapshot transactions have their own copy of the Transaction Inventory Pages ( TIP ), taken when the transaction started, transaction A couldn't see the state of transaction B or transaction C ( because they are not in this copy ).

    So I guess that snapshot transactions use its own copy of TIP for reading ( selects ), but when it comes to updates or deletes, in order to search for collisions, they should also access the global shared TIP.

Not exactly.  A snapshot transaction has a copy of rhe relevant section of the TIP as of the time it starts. Transactions started later alway count as "active" because they could not have committed before the started.  

When a snapshot transaction tries to update a record and finds that the most recent version was created by a transaction that was active or unknown according to its copy of the TIP, it attempts to take a lock on that transaction's id. 

Every transaction holds an exclusive lock on its id until it ends.  When the lock is granted to the waiting transaction, it knows that the other transaction has ended and asks the transaction management module for the final state of the dead transaction.  

Good luck,