Quoting "Brian Dillon (ext. 944)" <[EMAIL PROTECTED]>: > Hi, > > I have noticed that Transacton management is seems to be done on a per > thread basis. This leads to a situation whereby every request from a
This is so because it is meaning less for a client thread to be associated with more than one transaction simultaneously-- alternatively, any operation belongs to at most one transaction. > particular client must be routed to the same thread for every request ! Take > the situation where we have two Clients A and B; Each transaction is represented by its own Transaction object. The object may be associated with none, one or many threads at any point in time, that happen to do work that comes under the respective transaction. > > Client A starts a transaction. TransactionManager.begin() > Client A performs some transacted operation, but hasn't yet > committed/rolledback. Transaction tx1 = TransactionManager.suspend() > Client B starts a transaction TransactionManager.begin() > Client B performs some trasacted operation. say, A wants to do more work, then Transaction tx2 = TransactionManager.suspend() TransactionManager.resume(tx1) /// note that the commit/rollback methods of the TransactionManager only apply to the current tx. If you want to terminate a suspended tx then respective methods of the tx object must be used. > > If Client B's transacted operation happens to get serviced by the same > thread that Client A used (which is not uncommon in a Web Service) then you > get an exception; java.lang.IllegalStateException: the thread is already > associated with another transaction. > > Is there any known workaround for this, since this would mean that we could > not use Kandula in a multithreaded environment ? no work around is required. This is done implicitly by the TxHandler. Each time a request is received if it has a CoordinationContext a new local tx is either created or if there is a corresponding tx already, that tx is associated with the thread. On the return path, the tx is suspended. thanks, --dasarath > > Thanks, > > Brian Dillon > > ********************************************************************** > The information contained in this e-mail is confidential, may be > privileged and is intended only for the user of the recipient named above. > If you are not the intended recipient or a representative of the intended > recipient, you have received this e-mail in error and must not copy, use > or disclose the contents of this e-mail to anybody else. If you have > received this e-mail in error, please notify the sender immediately > by return e-mail and permanently delete the copy you received. > This e-mail has been swept for computer viruses. However, you should > carry out your own virus checks. > Registered in Ireland, No. 205721. http://www.FINEOS.com > ********************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
