> 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'
It is relevant only because you cited the double checked
locking. My point was that this problem had nothing to do
with the way txCapsule was being accessed but everything
to do with what happens within TxCapsule.
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).
The getStatus and getTransactionImpl methods aren't (and their
respective variables aren't volatile) which means they may
suffer from the same problem as the double checked locking.
If these variables are modified within one thread, are not
covered by synchronisation, then the changes may not be visible
in other threads.
> 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.
I agree but then so does using a volatile txCapsule and moving it
into a non-volatile to check and access. No synchronisation is
necessary, which was the point of the original change.
> 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.
Yep, but you cannot guarantee the source of the NPE. It is
feasible that the NPE could be generated by a problem in the
called methods and this code will hide that.
> I think we're really talking the same thing. Ole's pattern
> works, is ugly,
> other solutions are tricks and 'may' have issues.
It is not a trick, it is the correct use of volatile. The compilers
should not optimise the local variable into two access of the volatile.
It is syntactically incorrect and less efficient.
Do you have any reason to believe this is not the case? If you do then
I would genuinely like to hear about it.
> If you want to carry on flogging this horse, carry on....I'm
> happy as is.
:-)
Kev
Kevin Conner
Orchard Information Systems Limited
Newcastle Technopole, Kings Manor
Newcastle Upon Tyne, NE1 6PA. United Kingdom
Registered in England, Number 1900078
Tel: +44 (0) 191-2032536 Fax: +44 (0) 191 2302515
-------------------------------------------------------
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
