How are blind writes recoverable in a transaction schedule?

Question

Consider the following schedule -

T1     T2

R(A)
W(A)
       R(A)
       W(A)
       Commit
Commit

I understand that this schedule is non-recoverable, because if a failure occurs between the two commits, then we can't rollback the operations performed by T2, as they would already have been committed.

But, if we change this schedule to

T1     T2

R(A)
W(A)
       R(A)
       W(A)
Commit
       Commit

then this becomes recoverable, as if a failure now occurs immediately before T1's commit, then all the operations performed by T1 and T2 can be rolled back, and if a failure occurs between the two commits, then we can roll back only T2's operations and run only T2 separately again.

Now, everywhere that I've read about recoverable schedules, it is written that a recoverable schedule is one where, for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the commit operation of Ti appears before the commit operation of Tj.

So, if we go by this definition, then the following schedule must be recoverable -

T1     T2

R(A)
W(A)
       W(A)
       Commit
Commit

But, how is this schedule recoverable? In this case as well, if a failure occurs between the two commits, then we again can't roll back T2's W(A) operation, and if we roll back only T1's operations and run only T1 separately, then the final value that will be reflected in the database will be T1's W(A), when our original intention was to store T2's W(A) in the database.

Answer 1

T1     T2

R(A)
W(A)  
       W(A)
       Commit 
Commit

is not recoverable, even though it satisfies the condition you mentioned about the commit order of transactions. Let's walk through it:

1. T1 reads and writes A.
2. T2 writes A.
3. T2 commits.
4. T1 commits. If a failure occurs after T2's commit but before T1's commit, the system needs to be rolled back to a consistent state. But, in this case, the final state after rolling back would reflect T1's update to A, and the update from T2 would be lost.

This is a case where the criterion mentioned ("for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the commit operation of Ti appears before the commit operation of Tj") does not ensure recoverability when taken on its own. Recoverability also requires that the final committed state of the database reflects the actual intentions of the transactions.

Your analysis highlights a limitation in the definition you mentioned. Recoverability requires not only the commit order but also the preservation of the final intended updates. In a recoverable schedule, if a transaction Tj reads a value previously written by Ti, then Tj's commit should appear after Ti's commit to ensure that the intended effects of both transactions are correctly reflected in the committed state, even in the face of failures.