Dain Sundstrom wrote:
Ole Husgaard wrote:
+ // Using the construct
+ // try {
+ // txCapsule.doSomething();
+ // } catch (NullPointerException ex) {
+ // throw new IllegalStateException(No transaction.);
+ // }
+ // may look like bad
Maybe we should be a little more restrictive than JTA here,
and only allow reentrant calls to the transaction service
during the callouts when done on the same thread.
I think that would allow us to simply synchronize on the
methods of the TransactionImpl frontend.
The downside of
marc fleury wrote:
Maybe we should be a little more restrictive than JTA here,
and only allow reentrant calls to the transaction service
during the callouts when done on the same thread.
I think that would allow us to simply synchronize on the
methods of the TransactionImpl frontend.
The
Kevin Conner wrote:
As an aside, having just looked at the 3.0.1 code (this may
have changed since then), commit, delistResource, enlistResource,
registerSynchronization, rollback and setRollbackOnly are protected
by the lock method (and hence synchronisation).
Until my recent commit, the
Kevin Conner wrote:
As an aside, having just looked at the 3.0.1 code (this may
have changed since then), commit, delistResource, enlistResource,
registerSynchronization, rollback and setRollbackOnly are protected
by the lock method (and hence synchronisation).
Until my recent commit,
Ole Husgaard wrote:
+ // Using the construct
+ // try {
+ // txCapsule.doSomething();
+ // } catch (NullPointerException ex) {
+ // throw new IllegalStateException(No transaction.);
+ // }
+ // may look like bad programming style, but it
