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?

 

-bryan

 


From: Alex Boisvert [mailto:boisvert@intalio.com]
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