[
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12917702#action_12917702
]
Craig Muchinsky commented on GERONIMO-4576:
---
Any update on this issue? I have a situation where I need my application code
to have access to SQLExceptions raised when flushing SQL to the DB using a
transaction synchronization. The application code checks the SQL state to
determine of the exception was caused by a transient deadlock, and if so it
retries again. FYI, the Geronimo tx manager is being consumed as a subcomponent
of the Aries tx module.
Make persistence exceptions more visible to client
--
Key: GERONIMO-4576
URL: https://issues.apache.org/jira/browse/GERONIMO-4576
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: persistence
Affects Versions: 2.2
Environment: Linux, Windows
Reporter: Joe Bohn
Priority: Minor
Fix For: Wish List
See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the
original problem. That core problem was resolved. However, upon resolution
it was mentioned that it would be beneficial to report more specific failure
information back to the client. From GERONIMO-3907:
Ralf Baumhof - 06/May/08 06:17 AM
Today if have tested the new Geronimo release 2.1.1 (published on
28.04.2008). The problem is now fixed. If the server gets an error on trying
a commit, this error is now thrown to the web bean.
Exception text:
javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back,
presumably because setRollbackOnly was called during a synchronization:
Unable to commit: transaction marked for rollback Root Cause:
javax.transaction.TransactionRolledbackException : Transaction was rolled
back, presumably because setRollbackOnly was called during a synchronization:
Unable to commit: transaction marked for rollback
Unfortunately there is no proper root cause attached to the exception. So the
cause can only be seen in the server console, but can not be reported to the
user. It would be very nice if you could change this in a later release.
Thanks for your help.
Vincent MATHON - 06/Nov/08 02:03 AM
I agree that exceptions on the server side should not be thrown to the client
side since such exceptions types might not be known by the client. However,
for unit testing purpose, it is useful to attach the root cause to the
RollBackException. I have modified a few lines in
org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the
root cause in case of RollBackException and it works for my unit testing
purpose (I have not enough background on the java transaction architecture
topic to submit a patch for production). It would be great to define a
configuration parameter that permits to provide the root cause to the client
and keep the current behaviour that does not by default.
Geoff Callender - 22/Dec/08 03:36 AM
It's useful for more than unit testing - it's essential to be able to inform
the client what's wrong with the request. I've added some examples of this to
https://issues.apache.org/jira/browse/OPENEJB-782 .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
