>It's a two step process. An update marks the tuple locked. Another
>transaction which comes along and wants to lock the tuple waits on the
>transaction marked on the tuple. When the first transaction commits or
>aborts then the second transaction can proceed and lock the tuple
>itself.
I agree with it.
>The reason we need both locks is because the first transaction
>cannot go around the whole database finding every tuple it ever locked
>to unlock it, firstly that could be a very large list and secondly
>there would be no way to do that atomically.
You mean that 2PL is hard to realize actually, I agree too.
But it doesn't mean tuple lock is necessary.
>Tuple locks and all user-visible locks are indeed held until the end
>of the transaction.
I don't agree with it, for I see unlocktuple(...) in heap_update(...).
--Huang Xiaocheng
--Database & Information System Lab, Nankai University
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4671 (20091208) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com