My understanding was that each transaction would be bound to a thread, hence this would not be possible.
Overall, what I am missing is the motivation for decoupling the transaction and the thread in which it executes. Coupling these makes sense to me in the following way. Concurrency control is about managing concurrent access to resources. Threads are the mechanism for concurrency in Java. Given that, requiring a transaction to execute within a specific thread means that the concurrency control mechanism can be realized purely as synchronization for concurrent threads based on resource contention.
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?
[mailto:firstname.lastname@example.org] On Behalf Of Kevin Day
Sent: Monday, March 27, 2006 5:25 PM
To: JDBM Developer listserv
Subject: re: [Jdbm-developer] 2PL: transactions, threads and locking (rese nd!)
If I have 2 transactions that all attempt to grab a lock on the same resource, the following is a very likely scenario:
Both transactions are running in the same thread - in this case, synchronization constructs would not block at all (synchronization is re-entrant), and the transactions would be allowed to proceed, even though serialization may be violated.
That's why I'm thinking that the transaction has to be part of the lock request - I think the blocking operation needs to be done in the context of a thread/transaction pair - not just per thread. But maybe I'm misunderstanding your implementation's behavior.
I'll let Alex address the point of wanting to be able to hand a transaction from one thread to another, but I could definitely see where something to that effect would be necessary if workflow process queues are being used.
------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbmemail@example.com https://lists.sourceforge.net/lists/listinfo/jdbm-developer