This content has been marked as final.
Show 5 replies
-
1. Re: Transaction.commit() vs TransactionManager.commit(), thr
marklittle Jul 10, 2007 4:41 AM (in response to mr_dronski)Typically if a transaction is being terminated by something other than the creating thread, e.g., during transaction timeout.
-
2. Re: Transaction.commit() vs TransactionManager.commit(), thr
marklittle Jul 10, 2007 5:16 AM (in response to mr_dronski)For some other use cases, check out this as well as the OTS specification: direct versus indirect transaction management. Our manuals go into some detail on this too.
-
3. Re: Transaction.commit() vs TransactionManager.commit(), thr
mr_dronski Jul 10, 2007 10:01 AM (in response to mr_dronski)Thanks Mark. I've had this book on the night stand for half a year now :) And that is exactly what triggered my query.
In terms of ArjunaTS implementation, would it be the Reaper thread doing this, as well as resource association cleanup?
Andrew -
4. Re: Transaction.commit() vs TransactionManager.commit(), thr
adinn Jul 10, 2007 10:07 AM (in response to mr_dronski)Yes, the Reaper Thread (or one of its minions) would do this.
Andrew Dinn -
5. Re: Transaction.commit() vs TransactionManager.commit(), thr
marklittle Jul 10, 2007 10:18 AM (in response to mr_dronski)"mr_dronski" wrote:
Thanks Mark. I've had this book on the night stand for half a year now :)
And I hope you read it ;-)
And that is exactly what triggered my query.
In terms of ArjunaTS implementation, would it be the Reaper thread doing this, as well as resource association cleanup?
If you're talking about what we do automatically, then yes, that does some of this. From a strictly JEE perspective that's about it. However, once you move outside of JEE, to include Web Services and stand-alone, and allow multiple threads in the scope of the same transaction, compensations, interceptors etc, there are other places where direct transaction management occurs.
Then there's the fact the application can do this if it wants ;-)