Bugs item #731363, was opened at 2003-05-02 14:10 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=731363&group_id=22866
Category: JBossTX Group: v3.2 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Mark Little (marklittle) Assigned to: Adrian Brock (ejort) Summary: Transaction.commit/rollback and thread disassociation Initial Comment: I know the JTA specification is a little bit vague in this case, but the generally accepted notion of terminating a transaction via javax.transaction.Transaction is that it doesn't do thread-to-transaction disassociation: if you want that, then you use TransactionManager. The spec. should definitely be tightened up, but the intention was that the differences between Transaction and TransactionManager mapped to the differences between the direct and indirect transaction management of the OTS (JTS), i.e., terminating via Terminator or Current. If you go via Terminator then no thread-to- transaction disassociation occurs, whereas if you go via Current it does. Is there any chance the JBoss transaction implementation will change and follow what others do? Mark. ---------------------------------------------------------------------- >Comment By: Adrian Brock (ejort) Date: 2003-07-01 13:26 Message: Logged In: YES user_id=9459 Changed identified locations to use the transaction manager to disassociate the thread's transaction for other TMs ---------------------------------------------------------------------- Comment By: Mark Little (marklittle) Date: 2003-05-06 09:25 Message: Logged In: YES user_id=754951 There are a number of reasons for the different ways in which the transaction can be terminated, but the main one is for distributed transactions: if a centralised transaction manager service is used then it will not be able to keep track of which threads in remote processes are using a specific transaction. So, if it decides to terminate a transaction (e.g., because its timeout goes off) then it is impractical (and most times impossible) to assume it can go around an tell all threads in all processes that the transaction is dead. The best and most efficient way of telling them is to let it happen lazily when (and if) those threads next try to use the transaction. As to when (if) the JTA will change to be more explicit on this - I hope so :-) Mark. ---------------------------------------------------------------------- Comment By: David Jencks (d_jencks) Date: 2003-05-02 17:23 Message: Logged In: YES user_id=60525 I'll look into this. What good is a completed transaction associated with a thread? Is there any chance the jta spec will in fact change to specify this behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=731363&group_id=22866 ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
