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?




From: [] On Behalf Of Kevin Day
Sent: Monday, March 27, 2006 5:25 PM
To: JDBM Developer listserv
Subject: re[2]: [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.


- K 



Let me respond to both lines of questions here.  I dont think that I understand the requirements that are driving either (or both) of your questions. (However, it definitely helps to have agreement that a transaction is bound to a specific thread while that thread is executing).
Alex, it appears that you want explicit start/suspend/resume operations for transactions  why?  I would think that blocking on access to resources was sufficient to coordinate concurrent processing.
Kevin, I understand how you are asking to have things implemented, but I am again stuck on why?

From: Alex Boisvert []
Sent: Monday, March 27, 2006 3:34 PM
To: Thompson, Bryan B.
Cc: Kevin Day; JDBM Developer listserv
Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking (resend!)


Thanks for the explanation.  I understand that if a thread gets suspended within a transaction context, no other thread should be able to do work for that transaction until the thread is resumed and then transaction relinquished.

What I want to know is if I'd be able to do something like: tx = TransactionManager.start();[do some work]tx.suspend();  
and in another thread later: tx = [same transaction as above]tx.resume();[continue work for same transaction]tx.commit();

Would that be possible?


Thompson, Bryan B. wrote:  
-- resend --
If the method signature is lock( short mode ), then the thread is being defined by the callers 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 []
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.


------------------------------------------------------- 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! _______________________________________________ Jdbm-developer mailing list