[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532873#comment-15532873
]
Tuomas Kiviaho commented on GERONIMO-4576:
--
Preserving also the original {{SetRollBackOnlyException}} could be done as
follows
{code}
private void markRollbackCause(Throwable e) {
if (markRollbackCause == null) {
markRollbackCause = e;
} else if (markRollbackCause instanceof SetRollbackOnlyException) {
Throwable cause = markRollbackCause.getCause();
if (cause == null) {
markRollbackCause.initCause(e);
}
}
}
{code}
> 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
>
> Attachments: GERONIMO-4576-1.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986937#comment-14986937 ] xiezhi commented on GERONIMO-4576: -- It looks like in geronimo2.2.2. Please double check it. > 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 > > Attachments: GERONIMO-4576-1.patch > > > 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986936#comment-14986936 ] xiezhi commented on GERONIMO-4576: -- It looks like in geronimo2.2.2. Please double check it. > 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 > > Attachments: GERONIMO-4576-1.patch > > > 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604473#comment-14604473 ] vishnu commented on GERONIMO-4576: -- I am also facing similar kind of issue with tomee 1.6.1 with java 1.6 . Any idea which verstion of tomee has this fix from geronimo.Is it possible use class file TransactionImp directly to fix this issue in tomee library open-core 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 Attachments: GERONIMO-4576-1.patch 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604475#comment-14604475 ] vishnu commented on GERONIMO-4576: -- I am also facing below issue sometimes if ran test scenarion multiple times and intermediate . Caused by: javax.persistence.TransactionRequiredException: no transaction is in progress at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:301) I have looked at all the transaction isolation levels and other exeption handling to roll back transaction properly.No luck. do you think this is also kind of issue of hiding original exception .Because i don't see any thing loosing of transaction in the middle as everything handled correctly. Thanks 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 Attachments: GERONIMO-4576-1.patch 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604498#comment-14604498 ] vishnu commented on GERONIMO-4576: -- i have checked the geronimo-transaction-3.1.2 and geronimo-transaction-3.1.3 jars for the patch GERONIMO-4576-1.patch[ 12684899 ] in TransactionImpl.class , don't see . By the way which version has this patch. 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 Attachments: GERONIMO-4576-1.patch 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598790#comment-13598790 ] andrew shililday commented on GERONIMO-4576: Freeman, Hi. Did you manage to get around the problem in any way without changing the source code? I'm not really in a position to change the code, but in my application I really need to differentiate between OptimisticLockExceptions versus more critical underlying persistence provider or jdbc exceptions. 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598798#comment-13598798 ] Freeman Fang commented on GERONIMO-4576: Hi Andrew, No, I must change the source code for my case. Cheers Freeman 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598548#comment-13598548 ] Freeman Fang commented on GERONIMO-4576: Hi, Yeah, I ran into same issue recently, the SetRollbackOnlyException hide real root cause if we call setRollbackOnly() method. And I'm OK with your option 1 3. Thanks Freeman 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597701#comment-13597701 ] andrew shililday commented on GERONIMO-4576: Vamsavardhana's last comment is spot on. The setRollbackOnly() method calls the setRollbackOnly(Throwable) method with a newly created and unmeaningful SetRollbackOnlyException. The call to setRollbackOnly(Throwable) sets the markRollbackCause field which prevents a later call to markRollbackCause (with a reasonable exception) to be ignored (because the markRollbackCause is only updated if it's null). There are three ways you might fix the problem: 1) change the single call in the setRollbackOnly() method to call setRollbackOnly with null instead of a new exception (then, when markRollbackCause is later called, it will be able to set the variable). 2) change the behavior of markRollbackCause() to update the field even if it's not null (this isn't really recommended). 3) change the behavior of markRollbackCause() such that if the current cause is a SetRollbackOnlyException, change the cause for the SetRollbackOnlyException to be the actual underlying exception. 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13539252#comment-13539252 ] Geoff Callender commented on GERONIMO-4576: --- Well this is sad. Nearly 5 years on since the problem began with GERONIMO-3907 and still I have to use a ridiculous workaround I described 4 years ago in https://issues.apache.org/jira/browse/OPENEJB-782 - inside the transaction I manually flush in a try-catch block and convert the exception to one of my own. 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032289#comment-13032289 ] Vamsavardhana Reddy commented on GERONIMO-4576: --- I see that 2.2 revs 1097555 and 1097965 are also related to this JIRA. 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
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002205#comment-13002205 ] David Jencks commented on GERONIMO-4576: So now we're showing the first exception to cause the rollback as the cause in 2.1.1 rev 1076789 2.2 rev 1076770 trunk (3.1.1??) rev 1076767 possible future trunk (4??) (my sandbox) rev 1073479 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
[jira] Commented: (GERONIMO-4576) Make persistence exceptions more visible to client
[ 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.
