[
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032411#comment-13032411
]
Vamsavardhana Reddy commented on GERONIMO-4576:
-----------------------------------------------
I notice that revs 1097555 and 1097965 are once again masking the original
persistence exception and putting a SetRollbackOnlyException() as the cause. To
give an example, with rev 1076770 applied in my code, I am getting the
following exception report:
REPORT-1:
org.apache.jasper.JasperException: 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.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.RollbackException: Unable to commit: transaction marked for
rollback
root cause:
<openjpa-1.2.2-r422266:898935 fatal general error>
org.apache.openjpa.persistence.PersistenceException: The transaction has been
rolled back. See the nested exceptions for details on the errors that occurred.
...
--------------
With revs 1076770, 1097555 and 1097965 applied in my code, I am getting the
following exception report in the same case (notice that the persistence
exception is lost):
REPORT-2:
org.apache.jasper.JasperException: 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.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.RollbackException: Unable to commit: transaction marked for
rollback
root cause:
org.apache.geronimo.transaction.manager.SetRollbackOnlyException:
setRollbackOnly() called. See stacktrace for origin
--------
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
