This content has been marked as final.
Show 5 replies
-
1. Re: Exceptionhandling in distributed transactions
marklittle Jun 6, 2006 10:33 AM (in response to peter_p)"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. -
2. Re: Exceptionhandling in distributed transactions
marklittle Jun 6, 2006 10:50 AM (in response to peter_p)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.
-
3. Re: Exceptionhandling in distributed transactions
peter_p Jun 7, 2006 2:19 AM (in response to 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. -
4. Re: Exceptionhandling in distributed transactions
marklittle Jun 7, 2006 6:24 AM (in response to peter_p)"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.