From: Thompson, B. B. <BRY...@sa...> - 2006-03-27 20:50:09
|
Let me respond to both lines of questions here. I don't 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?" Thanks, -bryan _____ From: Alex Boisvert [mailto:boi...@in...] 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!) Bryan, 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? alex Thompson, Bryan B. wrote: -- resend -- Alex, 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. -bryan _____ From: Alex Boisvert [mailto:boi...@in... <mailto:boi...@in...> ] 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. Bryan, Can you elaborate on why the same thread must be used for the life of a transaction? alex 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. -bryan |