Each transactions has its own local variables. When it reads from the database, it copies values from the database to its local variables. When it writes to the database, it copies values from its local variables to the database.
Kalle, who has bank account K, wants to give 50 to Lotta, who has bank account L.
At almost the same time, Lotta's salary is paid, by depositing 10000 in Lotta's account, L.
A serial schedule.
Another serial schedule.
A non-serial schedule. What happen's to Kalle's 50?
A figure from the course textbook by Elmasri and Navathe.
Any serial schedule is considered correct, but two serial schedules need not give the same result.
Lotta wants to give away all her money to Kalle.
The same thing, with locks on L and K.
Kalle wants to give away all his money to Lotta.
A possible schedule, given the locking operations on K and L. Is this a correct schedule?
The result of the schedule above. This is not a correct result, since no serial schedule could give this result. Therefore, the schedule above is not serializable, and thus not a correct schedule.
The principle behind the time-stamp method: let operations travel in time, and use time-stamps on all data items to detect time-travel inconsistencies.
The database, when running the example.
The beginning of the log file, when running the example.
