Any particular reason that all locks are given up at the end? Why not unlock resources when they're done being used (e.g., call UNLOCK(A) after READ(A)). This seems like it may improve throughput.
russt17
Could it be in case future writes depend on the read or something? Like for example here if we were reading the value from A and then writing it into B?
jcarchi
Also, in case you might need to roll back?
grose
Perhaps the locking is being used to carry out the communication for pessimistic transactions, since the previous slide mentions 2PL is pessimistic
ak47
Releasing locks early leads to a problem known as cascading abort or cascading rollback, where a dirty read causes multiple transactions to roll back. Holding locks until the end is called strict two phase locking and fixes this.
Any particular reason that all locks are given up at the end? Why not unlock resources when they're done being used (e.g., call UNLOCK(A) after READ(A)). This seems like it may improve throughput.
Could it be in case future writes depend on the read or something? Like for example here if we were reading the value from A and then writing it into B?
Also, in case you might need to roll back?
Perhaps the locking is being used to carry out the communication for pessimistic transactions, since the previous slide mentions 2PL is pessimistic
Releasing locks early leads to a problem known as cascading abort or cascading rollback, where a dirty read causes multiple transactions to roll back. Holding locks until the end is called strict two phase locking and fixes this.