[paul.robinson]

Tom,

Re: When something goes wrong internally to the implementation of the TransactionInterceptor or TransactionalContext, what RuntimeException should I throw?

It doesn't seem to be specified, so I'm thinking I can just throw some Narayana specific RuntimeException.

Can you provide an example, at the moment I am thinking javax.transaction.TransactionalException (from 3.7: Transactional Annotation)

Yes, I think I can use TransactionalException in the transaction interceptors. However, I was more thinking about what to do in the TransactionalContext. Here's an example:

The TransactionalContext needs to lookup the transaction manager. If this fails, a javax.transaction.SystemException is thrown. This has to be handled (it extends Exception) and the Context interface does not declare that any checked exceptions can be thrown from its methods. Therefore I need to wrap the javax.transaction.SystemException in some unchecked transaction.

TransactionalException is the only RuntimeException in the JTA 1.2 spec, so I'll just use whatever general unchecked exception we use in the JTA 1.1 implementation.

[marklittle]

As soon as WF moves to adopt EE7 for all of its constituent components then JTA 1.2 should be the default.

[paul.robinson]

Mark,

Mark Little wrote:

What I said was only partially correct. We call end on suspended RMs if delist hasn't been called. Having this happen for all RMs is easy, but we'd have to be aware of interface changes and semantic changes, since it is not backwardly compatible *unless* we have this as a configurable option. Worth considering though, since JTA 1.2 adoption will take a while.

Mike and I have looked over the code, and we think that we already comply to this spec point. Take a look at the explanation I added to the "Other Spec Changes" section.

[tomjenkinson]

Paul Robinson wrote:

Mark,

Mark Little wrote:

What I said was only partially correct. We call end on suspended RMs if delist hasn't been called. Having this happen for all RMs is easy, but we'd have to be aware of interface changes and semantic changes, since it is not backwardly compatible *unless* we have this as a configurable option. Worth considering though, since JTA 1.2 adoption will take a while.

Mike and I have looked over the code, and we think that we already comply to this spec point. Take a look at the explanation I added to the "Other Spec Changes" section.

I have taken a look at this too and agree XAResource::end(TMSUCCESS) does seem to be called in all permutations. I wonder if TMFAIL might be more appropriate for topLevelAbort? However, I open this as a point of discussion, rather than suggestion. In practical terms I suspect it won't make any difference to the RM.

Also, your description in "Other Spec Changes" omits the fact that  com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple::rollback(), endSuspendedRMs() is also invoked. Near as I can work out though, endSuspendedRMs is almost superflous as topLevel* will end ASSOCIATION_SUSPENDED branches anyway?

[paul.robinson]

Thanks Tom,

Tom Jenkinson wrote:

Also, your description in "Other Spec Changes" omits the fact that  com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple::rollback(), endSuspendedRMs() is also invoked.

Updated.

Tom Jenkinson wrote:

Near as I can work out though, endSuspendedRMs is almost superflous as topLevel* will end ASSOCIATION_SUSPENDED branches anyway?

It seems that way to me, but I may well be missing some corner-case.

[marklittle]

No code changes for this is even better then It has been a while since that code was written

[paul.robinson]

Mark,

Mark Little wrote:

No code changes for this is even better then It has been a while since that code was written

Yes, that pleased me too!

Thanks for checking.