-- resend --
If the method signature is lock( short mode ), then the thread is being defined by the caller’s execution context:
tx := the thread in which the caller was executing.
If a lock request must block, the code executes: tx.wait()
When a requested lock can be granted, the code executes: tx.notifyAll()
All of this synchronization relies on blocking the thread in which the transaction is executing so that it can not do any work. If you “assign” the transaction to a different thread during arbitrary points in its life cycle, then the wrong transactions will wind up blocked and/or running.
From: Alex Boisvert [mailto:firstname.lastname@example.org]
Sent: Monday, March 27, 2006 3:13 PM
To: Thompson, Bryan B.
Cc: Kevin Day; JDBM Developer listserv
Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking.
Can you elaborate on why the same thread must be used for the life of a transaction?
Thompson, Bryan B. wrote:
The semantics imposed by the API signature: lock( mode )
Is that the thread of the caller is blocked. This is basically the same semantics that the java.util.concurrent.Lock interface is using except that the latter does not have a lock mode. When the lock can not be granted immediately the current thread waits. When the lock can be granted, the thread is notified.
There is no constraint against reuse of a thread for executing different transactions at different times, but the same thread must be used through the life of any given transaction. If the responsibility for executing a given transaction is handled by t1 at one moment and t2 at another moment, then all of the synchronization logic would break.