Ok. I agree with that. -bryan
From: Alex Boisvert [mailto:firstname.lastname@example.org]
Sent: Monday, March 27, 2006 6:56 PM
To: Thompson, Bryan B.
Cc: Kevin Day; JDBM Developer listserv
Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking (rese nd!)
Thompson, Bryan B. wrote:
However, given that the requirement for transaction != thread is motivated, I have questions about the impact on the synchronization logic. For example, given:
Thread t1=…., t2 =…; // some threads.
Transaction tx1 = …, tx2 = ….; // some transactions.
Queue r1 = …; // queue for resource R1.
[t1 is executing tx1; t2 is executing tx2].
[ thread t1 ] r1.lock( tx2, ‘X’ ); // t1 requests a lock for tx2 on resource r1 in exclusive mode.
What happens? If the lock can not be granted immediately, does t1 block? There is absolutely no way to immediately block t2. Java synchronization does not provide for this as far as I can tell. How do you support “blocking” a transaction if a transaction is not bound to a thread – at least for the moment?
I don't think this should be allowed because thread t1 is not associated by tx2. That's why I don't think passing the transaction as part of the request makes sense.