geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Muchinsky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (GERONIMO-4576) Make persistence exceptions more visible to client
Date Mon, 04 Oct 2010 18:49:33 GMT

    [ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.


Mime
View raw message