From: Thompson, B. B. <BRY...@sa...> - 2006-03-27 20:24:17
|
-- 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...] 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 |
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 |
From: Kevin D. <ke...@tr...> - 2006-03-27 22:20:48
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Tahoma> <DIV><FONT face=Arial size=2>Bryan-</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>If I have 2 transactions that all attempt to grab a lock on the same resource, the following is a very likely scenario:</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>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.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>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.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>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.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>- K</FONT> </DIV> <DIV><FONT face=Arial size=2> </FONT> <TABLE> <TBODY> <TR> <TD width=1 bgColor=blue><FONT face=Arial size=2></FONT></TD> <TD><FONT face=Arial size=2><FONT color=red>> <BR>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). <BR> <BR>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. <BR> <BR>Kevin, I understand how you are asking to have things implemented, but I am again stuck on why? <BR> <BR>Thanks, <BR> <BR>-bryan <BR> <BR><BR><BR>From: Alex Boisvert <A href="mailto:boi...@in..."><FONT color=#0000ff>[mailto:boi...@in...]</FONT></A> <BR>Sent: Monday, March 27, 2006 3:34 PM<BR>To: Thompson, Bryan B.<BR>Cc: Kevin Day; JDBM Developer listserv<BR>Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking (resend!) <BR> <BR><BR>Bryan,<BR><BR>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.<BR><BR>What I want to know is if I'd be able to do something like: tx = TransactionManager.start();[do some work]tx.suspend(); <BR>and in another thread later: tx = [same transaction as above]tx.resume();[continue work for same transaction]tx.commit(); <BR><BR>Would that be possible?<BR><BR>alex<BR><BR><BR>Thompson, Bryan B. wrote: <BR>-- resend -- <BR> <BR>Alex, <BR>If the method signature is lock( short mode ), then the thread is being defined by the callers execution context: <BR> <BR>tx := the thread in which the caller was executing. <BR> <BR>If a lock request must block, the code executes: tx.wait() <BR> <BR>When a requested lock can be granted, the code executes: tx.notifyAll() <BR> <BR>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. <BR> <BR>-bryan <BR> <BR><BR><BR>From: Alex Boisvert <A href="mailto:boi...@in..."><FONT color=#0000ff>[mailto:boi...@in...]</FONT></A> <BR>Sent: Monday, March 27, 2006 3:13 PM<BR>To: Thompson, Bryan B.<BR>Cc: Kevin Day; JDBM Developer listserv<BR>Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking. <BR> <BR><BR>Bryan,<BR><BR>Can you elaborate on why the same thread must be used for the life of a transaction?<BR><BR>alex<BR><BR><BR>Thompson, Bryan B. wrote: <BR>The semantics imposed by the API signature: lock( mode ) <BR> <BR>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. <BR> <BR>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. <BR> <BR>-bryan <BR> <BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML> |
From: Alex B. <boi...@in...> - 2006-03-27 23:46:30
|
The way I understand it, we would only have one transaction associated with a thread. In pseudo-code form, the lock code would be something like: public void lock( Object resource, short mode ) throws ... { Transaction tx = _threadLocalTx.get(); synchronized ( _locks ) { Lock lock = _locks.get( resource ); if ( lock.owner.equals( tx ) ) { // already owner // upgrade lock if necessary return; } } } So there would be no need to pass around the transaction object, and no risk of having two transactions associated with a thread, or two threads associated with a transaction if we correctly protect the entrypoints (begin, suspend, resume, commit). alex Kevin Day wrote: > Bryan- > > 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 |
From: Kevin D. <ke...@tr...> - 2006-03-28 01:09:38
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Tahoma> <DIV><FONT face=Arial size=2>Alex-</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>As long as you have a mechanism for guaranteeing that only a single transaction is 'active' in a given thread at a given time, then I am in agreement with you. Explicitly suspend and resuming a transaction is an interesting idea here - and definitely one that has quite a bit of merrit. </FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>If you did pass in the transaction to the call, then the user wouldn't have to do explicit suspend/resume, etc... but I'm not at all sure if that would be an advantage or a disadvantage.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Having explicit suspend/resume forces the developer into a certain programming style - but one that is definitely 'best practices'. The suspend/resume mechanism would certainly address my concerns about NB IO, and it does simplify the architecture, so that's a design trade-off that I'm willing to accept.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>- K</FONT></DIV> <DIV><FONT face=Arial size=2> </FONT> <TABLE> <TBODY> <TR> <TD width=1 bgColor=blue><FONT face=Arial size=2></FONT></TD> <TD><FONT face=Arial size=2><FONT color=red>> The way I understand it, we would only have one transaction associated with a thread.<BR><BR>In pseudo-code form, the lock code would be something like:<BR><BR>public void lock( Object resource, short mode ) throws ...<BR>{<BR> Transaction tx = _threadLocalTx.get();<BR><BR> synchronized ( _locks ) {<BR> Lock lock = _locks.get( resource );<BR> if ( lock.owner.equals( tx ) ) {<BR> // already owner<BR> // upgrade lock if necessary<BR> return;<BR> }<BR> }<BR>}<BR><BR>So there would be no need to pass around the transaction object, and no risk of having two transactions associated with a thread, or two threads associated with a transaction if we correctly protect the entrypoints (begin, suspend, resume, commit).<BR><BR>alex<BR><BR><BR>Kevin Day wrote: <BR>Bryan- <BR> <BR>If I have 2 transactions that all attempt to grab a lock on the same resource, the following is a very likely scenario: <BR> <BR>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. <BR> <BR>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 maybeI'm misunderstanding your implementation's behavior. <BR> <BR>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. <BR> <BR>- K <BR><BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML> |
From: Alex B. <boi...@in...> - 2006-03-27 22:48:36
|
Thompson, Bryan B. wrote: > > > 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. > > > The suspend/resume operations only make sense if you want to multiplex work for several transactions in a single thread, as is the case for the non-blocking IO scenario. alex |
From: Thompson, B. B. <BRY...@sa...> - 2006-03-27 23:44:35
|
Alex, Can you expand on the non-blocking IO scenario? Why don't you just hand off execution to another thread associated with the transaction? -bryan _____ From: Alex Boisvert [mailto:boi...@in...] Sent: Monday, March 27, 2006 5:47 PM To: Thompson, Bryan B. Cc: Kevin Day; JDBM Developer listserv Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking (resend!) Thompson, Bryan B. wrote: 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. The suspend/resume operations only make sense if you want to multiplex work for several transactions in a single thread, as is the case for the non-blocking IO scenario. alex |
From: Alex B. <boi...@in...> - 2006-03-28 00:13:14
|
I am more thinking about the case where you've designed, say, a single-threaded server that uses non-blocking I/O and handles multiple concurrent requests. In this case you would want this thread to perform work on behalf of multiple outstanding transactions using Transaction.suspend() and Transaction.resume(). Or, another case is you have a SEDA-style architecture with multiple stages. Each stage has its own thread-pool. Assuming you don't have parallel processing in your transaction (or with proper synchronization if you do) you can have a transaction go through multiple stages and hence driven by different threads using the suspend() and resume() semantics. alex Thompson, Bryan B. wrote: > Alex, > > > Can you expand on the non-blocking IO scenario? Why don't you just > hand off execution to another thread associated with the transaction? > > =20 > > -bryan > > =20 > > = ------------------------------------------------------------------------ > > *From:* Alex Boisvert [mailto:boi...@in...] > *Sent:* Monday, March 27, 2006 5:47 PM > *To:* Thompson, Bryan B. > *Cc:* Kevin Day; JDBM Developer listserv > *Subject:* Re: [Jdbm-developer] 2PL: transactions, threads and locking > (resend!) > > =20 > > Thompson, Bryan B. wrote: > > =20 > > 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. > > =20 > > The suspend/resume operations only make sense if you want to multiplex > work for several transactions in a single thread, as is the case for > the non-blocking IO scenario. > > alex > |
From: Kevin D. <ke...@tr...> - 2006-03-28 00:59:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Tahoma> <DIV><FONT face=Arial size=2>Bryan-</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>Certainly (I'll dig into the rest of the discussion later on, but I think it's worth doing the non blocking deal now):</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Thread per transaction works up to a certain number of simultaneous transactions. For example, a web server generally uses a thread pool, and passes each request off to a dedicated thread for handling that request.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>The problem with this is that in high performance (and very high concurrency) systems, the overhead of a thread context switch becomes significant. A good example is a telephony routing system - in this case, a threaded application may be able to handle 50 or 100 simultaneous calls - after that, the overhead of flipping between threads kills the throughput.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>This is where non blocking IO comes in - in non-blocking IO, you have a single thread that handles ALL requests. Each packet of info that is received is processed through an object that also receives context information to allow it to know what context to handle the data in. This style of programming is much closer to state machine programming than multi-threaded, structured programming - but it definitely has it's place. I've heard reports of systems going from 50 simultaneous transactions to tens of thousands.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Anyway, the point here is that you could easily wind up with a single thread having multiple simultaneous (and potentially conflicting) transactions. Handing execution off to another thread would have a serious negative impact on overall system throughput...</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Normally, I wouldn't be too concerned by this - but given that we are beating ourselves up for high concurrency, I think that it would be a mistake to neglect the mechanism used by the most highly concurrent applications in development today... I'd love to see a non-blocking high throughput data server (maybe a VoIP application) that uses jdbm2 as an embedded database...</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>- K</FONT></DIV> <DIV><FONT face=Arial size=2> </FONT> <TABLE> <TBODY> <TR> <TD width=1 bgColor=blue><FONT face=Arial size=2></FONT></TD> <TD><FONT face=Arial size=2><FONT color=red>> <BR>Alex, <BR><BR>Can you expand on the non-blocking IO scenario? Why dont you just hand off execution to another thread associated with the transaction? <BR> <BR>-bryan <BR> <BR><BR><BR>From: Alex Boisvert <A href="mailto:boi...@in..."><FONT color=#0000ff>[mailto:boi...@in...]</FONT></A> <BR>Sent: Monday, March 27, 2006 5:47 PM<BR>To: Thompson, Bryan B.<BR>Cc: Kevin Day; JDBM Developer listserv<BR>Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking (resend!) <BR> <BR>Thompson, Bryan B. wrote: <BR> <BR>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. <BR> <BR>The suspend/resume operations only make sense if you want to multiplex work for several transactions in a single thread, as is the case for the non-blocking IO scenario.<BR><BR>alex <<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML> |
From: Kevin D. <ke...@tr...> - 2006-03-27 20:32:27
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Tahoma> <DIV><FONT face=Arial size=2>Bryan-</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>I think this is going to be overly restrictive. Much better to make the method signature lock(short mode, Transaction tx)...</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>The transaction object itself would have a 'current owner thread' attribute. If the attribute is set, and the current thread is not the owner, then the call fails spectacularly. If the attribute is not set, then the current owner thread is set until the lock is released... </FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Natch, we could also hold a lookup table for current thread data inside the locking sub-system, if we don't want to blur the boundaries of the layers. I think that this may be an instance where bluring the boundaries would be justified, though...</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>- K</FONT></DIV> <DIV><FONT face=Arial size=2> </FONT> <TABLE> <TBODY> <TR> <TD width=1 bgColor=blue><FONT face=Arial size=2></FONT></TD> <TD><FONT face=Arial size=2><FONT color=red>> <BR>-- resend -- <BR> <BR>Alex, <BR>If the method signature is lock( short mode ), then the thread is being defined by the callers execution context: <BR> <BR>tx := the thread in which the caller was executing. <BR> <BR>If a lock request must block, the code executes: tx.wait() <BR> <BR>When a requested lock can be granted, the code executes: tx.notifyAll() <BR> <BR>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. <BR> <BR>-bryan <BR> <BR><BR><BR>From: Alex Boisvert <A href="mailto:boi...@in..."><FONT color=#0000ff>[mailto:boi...@in...]</FONT></A> <BR>Sent: Monday, March 27, 2006 3:13 PM<BR>To: Thompson, Bryan B.<BR>Cc: Kevin Day; JDBM Developer listserv<BR>Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking. <BR> <BR><BR>Bryan,<BR><BR>Can you elaborate on why the same thread must be used for the life of a transaction?<BR><BR>alex<BR><BR><BR>Thompson, Bryan B. wrote: <BR>The semantics imposed by the API signature: lock( mode ) <BR> <BR>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. <BR> <BR>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. <BR> <BR>-bryan <BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML> |
From: Alex B. <boi...@in...> - 2006-03-27 20:35:51
|
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 =3D TransactionManager.start(); [do some work] tx.suspend(); and in another thread later: tx =3D [same transaction as above] tx.resume(); [continue work for same transaction] tx.commit(); Would that be possible? alex Thompson, Bryan B. wrote: > -- resend -- > > =20 > > Alex, > > If the method signature is _lock( short mode )_, then the thread is > being defined by the caller's execution context: > > =20 > > tx :=3D the thread in which the caller was executing. > > =20 > > If a lock request must block, the code executes: _tx.wait()_ > > =20 > > When a requested lock can be granted, the code executes: = tx.notifyAll() > > =20 > > 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. > > =20 > > -bryan > > =20 > > = ------------------------------------------------------------------------ > > *From:* Alex Boisvert [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. > > =20 > > > 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 ) > > =20 > > 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. > > =20 > > 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. > > =20 > > -bryan > > =20 > |