Dain Sundstrom wrote:
>
> 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 is needed to avoid to
> > + // synchronize on these methods. If we used a construct like
> > + // if (txCapsule == null)
> > + // throw new IllegalStateException("No transaction.");
> > + // txCapsule.doSomething();
> > + // we can get spurious NullPointerExceptions when racing with the
> > + // transaction completion.
> > +
> >
> > public void commit()
> > throws RollbackException,
> > @@ -68,9 +83,11 @@
> > java.lang.IllegalStateException,
> > SystemException
> > {
> > - if( txCapsule == null )
> > + try {
> > + txCapsule.commit();
> > + } catch (NullPointerException ex) {
> > throw new IllegalStateException("No transaction.");
> > - txCapsule.commit();
> > + }
>
> Interesting... Is this actually faster then synchronizing? Have you
> measured it?
No, except for running the testsuite, and no difference
could be observed there.
Looking back, I see that I should have stated more explicit
why I don't synchronize on the methods.
Reason for this is that the JTA specification IMHO isn't
restrictive enough about what can be done with transactions.
After entering one of these methods, the transaction service
may call out, either to xa resources or to synchronizations.
For example, when commit is called, a Sync.beforeCompletion()
is called, and there will be no return from the commit()
method until that synchronization method returns.
If I make the TransactionImpl methods synchronized, the
monitor of the transactionImpl object will remain locked
during the entire commit.
Now, let us assume that the Sync.beforeCompletion() wants to
roll back the transaction by calling rollback() on the (now
locked) TransactionImpl instance.
If the rollback() call is done on the same thread that
originally called commit(), there should be no problem.
Unfortunately, I don't see JTA saying that such a reentrant
call must come on the same thread.
If the Sync.beforeCompletion() implementation lets another
thread call rollback() on the transaction instance, and if
the Sync.beforeCompletion() does not return until the other
thread has returned from the rollback() method, we have a
deadlock.
> About a month ago I saw a presentation on Hot Spot and they claim that
> the synchronized keyword has very little over head (something like 3
> extra stack pushed and a lock grab), but exception handling like this
> can be very expensive because Hot Spot purposely does not optimize
> exception handling (which means that an exception can cost 100-1000
> times longer then the non-excetion code).
That is a big difference.
Add to that the wierd locking I do in TxCapsule.
> The only way I could see that this code be faster is if there is a lot
> of contention. Is there?
Congestion is rare.
In TxCapsule, a warning "Lock contention, tx=XXX" is logged
whenever it is detected.
All of this wierd locking code is due to the fact that we have
to call out from the transaction service to Synchronizations
and XAResources, and that JTA allows reentrant calls to come back
during these callouts ON DIFFERENT THREADS.
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 that would be that we could not change the
transaction service to callout to Synchronizations and XA
resources in parallel, because that would mean that a thread
from one of these callouts might not be the same as the
thread that originally locked the frontend.
What do you think?
Best Regards,
Ole Husgaard.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
