On Thu, Jul 18, 2002 at 12:24:50PM +0100, Kevin Conner wrote:
> > The code is structured this way (catching NPE's) to avoid
> > synchronization as
> > stated in the comment in the code. If all the methods in
> > TransactionImpl were
> > synchronized there would be no problem, apart from the
> > performance. Whether
> > txCapsule is synchronized is irrelevant.
>
> No, the code is structured this way to avoid the race between
> checking the volatile reference and accessing it. Whether
> txCapsule is synchronised is very relevant because the assumption
> in the code is that txCapsule is thread safe. It is the
> responsibility of txCapsule to make sure that all data accessed
> within is correct.
OK, the fact that TxCapsule is thread-safe *is* important in the overall
scheme of things, but for the purpose of this argument, 'Is there a better
way than catching the NPE's it's not'
If every method commit(), rollback(), delistResource() etc. were
of the form
synchronized doSomething() {
if (txCapsule == null)
throw new IllegalStateException("No transaction.");
txCapsule.doSomething();
}
Then there would be no problem 'cos the setDone() method is also synchronized.
txCapsule cannot change between the check and the access. By using Ole's
pattern of catching the NPE, you effectively make the check and access an
atomic action -> no race possible.
I think we're really talking the same thing. Ole's pattern works, is ugly,
other solutions are tricks and 'may' have issues.
If you want to carry on flogging this horse, carry on....I'm happy as is.
--
regards
Neale Swinnerton
-------------------------------------------------------
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
