Exceptionhandling in distributed transactions

[peter_p]

Hello,

I have installed JBossTS 4.2 into jboss-4.0.3SP1 using the instructions
in the INSTALL file that comes with JBossTS and configured the interposition
interceptor in iiop-service.xml.
After booting the "all" configuration I tried to run the following exception
test:

My client calls a StatelessSessionBean which in turn calls another
StatelessSessionBean on a different JBoss instance. The last one obtains a
UserTransaction-Object, calls setRollbackOnly and throws a UserException.
( simple exceptionclass derived from java.lang.Exception )

The Exception unwinds the callgraph to the TxInterceptorCMT of the first
instance ( all my beans use container managed transactions ) where the
interceptor queries the state of the TX and gets the result TRANSACTION_ACTIVE.
Due to this result the interceptor tries to commit the TX and receives a
RollbackException from the TX-Coordinator which in turn is reflected to the
client. The whole TX is rolled back but original UserException gets lost.

If I call setRollbackOnly and throw the UserException in the first SessionBean,
the interceptor will detect the TX state STATUS_MARKED_ROLLBACK and rolls back
the exception. The UserException will be reflected to the clientapplication
as expected.

Is this behaviour a bug or do I have to handle the UserTransaction in the
first SessionBean and call setRollbackOnly manually?

Thanks,
Peter

PS.:
When looking into the source code of the arjuna packages I found a
lot of exceptionhandlers that catch an original exception and throw
a new exception without logging or chaining them. The original reason
will be lost in such case.
( e.g. com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple )

[marklittle]

"peter_p" wrote:
Hello,

I have installed JBossTS 4.2 into jboss-4.0.3SP1 using the instructions
in the INSTALL file that comes with JBossTS and configured the interposition
interceptor in iiop-service.xml.

Hopefully you either mean JBossTS 4.2.1Beta 1, or that you used the installation instructions on the download page, as it clearly states on the download page?

PS.:
When looking into the source code of the arjuna packages I found a
lot of exceptionhandlers that catch an original exception and throw
a new exception without logging or chaining them. The original reason
will be lost in such case.
( e.g. com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple )

Thanks, we'll take a look. Depends what you mean by "a lot", but the code's been around for 10 years and obviously some things get overlooked. However, in the case of JTS, it's often impossible to chain exceptions because the CORBA binding doesn't support them.

[marklittle]

In the case of a distributed transaction, if you mark a downstream node as rollback-only, the specifications (OTS in this case) don't require that this fact is propagated throughout all of the other nodes. All that is required is that the outcome of the transaction will ultimately be to roll back. Calls to getStatus within a process for a distributed transaction are ultimately a snapshot of the local state of the transaction and you cannot infer from that the global status.

[peter_p]

Thank you for the quick reply.

Hopefully you either mean JBossTS 4.2.1Beta 1, or that you used the installation instructions on the download page, as it clearly states on the download page?

No, I installed the package JBossTS 4.2 some weeks ago. It works fine using the interposition interceptor.
Do you think I should give 4.2.1 Beta 1 a try, will it have another behaviour in exception handling?

Calls to getStatus within a process for a distributed transaction are ultimately a snapshot of the local state of the transaction and you cannot infer from that the global status.

Ok, I see but what about the lost of information from the clients point of view?
Would it be possible for the method endTransaction of TxInterceptorCMT to chain the original exception
with the new generated RollbackException and reflect both exceptions to the client?

In my opinion this would be a great benefit for the client because the error message would be more precise.

[marklittle]

"peter_p" wrote:
Thank you for the quick reply.

Hopefully you either mean JBossTS 4.2.1Beta 1, or that you used the installation instructions on the download page, as it clearly states on the download page?

No, I installed the package JBossTS 4.2 some weeks ago. It works fine using the interposition interceptor.
Do you think I should give 4.2.1 Beta 1 a try, will it have another behaviour in exception handling?

No, it won't have any affect on this, but there are some known issues with JacORB that are fixed if you follow the other instructions for 4.2: you don't need to move to 4.2.1 unless you want Web Services transactions support.

Calls to getStatus within a process for a distributed transaction are ultimately a snapshot of the local state of the transaction and you cannot infer from that the global status.

Ok, I see but what about the lost of information from the clients point of view?

Getting a global picture of events in a distributed system is complex and trade-offs need to be made. We could look at propagating more information back to the client, but as long as we log reasons somewhere in the system (e.g., at the point the problem happened) you can find out eventually. To be honest, many of our customers over the years are more interested in faulting and trying again as quickly as possible within their applications and dealing with permanent/repeated errors off-line by checking system logs.

Would it be possible for the method endTransaction of TxInterceptorCMT to chain the original exception
with the new generated RollbackException and reflect both exceptions to the client?

In my opinion this would be a great benefit for the client because the error message would be more precise.

We'd have to see: as I said before, if you're using OTS then chaining of exceptions may not be possible. We can certainly look at it for a subsequent release.

[marklittle]

http://jira.jboss.com/jira/browse/JBTM-86