7:07 p.m.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does not
affect manual debugging (the root cause is still logged higher up in the logs), but makes
it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:04 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Armin Haaf commented on JBTM-575:
---------------------------------
we have also a scenario on a client we need to unwrap the root cause. This "new"
behaviour breaks our client. We are migrating from 4.2.2 to 5.1 and we do not see a way
to fix it.
We are relying on jdbc constraint exception created by a hibernate flush. In 5.1 we only
get a "setRollbackOnly called from:" exception.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:04 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
Hi Richard
This does not make much sense to me. JBAS-4238 and JBTM-66 are similar but not equivalent.
The JBAS issue is addressed in both releases, but JBossAS 4.2.3 uses TS 4.2.3.SP7, which
does not have the JBTM-66 changes. JBossTS AS 5.1.0.GA uses TS 4.6.1.GA , which does. So,
you seem to be having problems due to a behaviour change that you requested in the first
place?! Ah well, maybe I misunderstood what you wanted. Do you have any preference
between the implementation alternatives I outline in
http://community.jboss.org/message/515473 assuming either will address your needs?
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:41 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Bozhidar Batsov commented on JBTM-575:
--------------------------------------
Hi, Jonathan,
I'm pretty certain that something is amiss. In 4.2.2.GA I used to get the real causes
of the exceptions from JBoss in my Swing client applications in case of constraint
violations for instance, now in 5.1.0.GA I only get a
java.lang.reflect.UndeclaredThrowableException
...
Caused by: javax.transaction.RollbackException:
[com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] ...
You have to agree that this is now particularly helpful. I don't know which of the
referred issues are fixed in TS 4.6.1 or not, but I'd like to ask you to verify this
behavior.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:27 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
crossing JVM boundaries is a whole other problem - if the chained exception class is not
available in the client classpath you suffer serious problems, so using chaining in that
use case is a bad idea anyhow.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:57 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
Jonathan,
Thanks for your response. I'm sorry if I haven't been clear in my description of
the problem.
I'm not convinced JBoss AS 5.1.0.GA actually includes JBTM-66, though I understand
JIRA seems to indicate it does. The fact remains that I (and others, by the look of it)
are seeing transaction RollbackExceptions *that do not include their root cause* when
using JBoss 5.1.0.GA.
For example, I see:
---
08:48:35,468 http-127.0.0.1-8080-6 DEBUG [SQL] delete from Resource where id=? and
version=?
08:48:35,484 http-127.0.0.1-8080-6 WARN [JDBCExceptionReporter] SQL Error: 1451,
SQLState: 23000
08:48:35,484 http-127.0.0.1-8080-6 ERROR [JDBCExceptionReporter] Cannot delete or update a
parent row: a foreign key constraint fails (`avant-ss-production/bug`, CONSTRAINT
`FK106546DD208B6` FOREIGN KEY (`assignedTo_id`) REFERENCES `resource` (`id`))
08:48:35,484 http-127.0.0.1-8080-6 ERROR [AbstractFlushingEventListener] Could not
synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not delete:
[com.avant.ss.ejb.entity.Staff#4028818126273479012627c550d60004]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at
org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2569)
at
org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2725)
at org.hibernate.action.EntityDeleteAction.execute(EntityDeleteAction.java:97)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:172)
at
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
at
org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:504)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1423)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:170)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:176)
at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:216)
at
org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
at
org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
at $Proxy354.delete(Unknown Source)
at
com.kennardconsulting.core.faces.controller.PersistentEntityController.delete(PersistentEntityController.java:259)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstValue.invoke(AstValue.java:170)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at
javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at
com.kennardconsulting.core.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:120)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:324)
at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:299)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:256)
at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:469)
at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.kennardconsulting.core.servlet.EjbRemoveFilter.doFilter(EjbRemoveFilter.java:44)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException: Cannot
delete or update a parent row: a foreign key constraint fails (`avant-ss-production/bug`,
CONSTRAINT `FK106546DD208B6` FOREIGN KEY (`assignedTo_id`) REFERENCES `resource` (`id`))
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2985)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1631)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1723)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3256)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1313)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1585)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1500)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1485)
at
org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
at
org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2551)
... 90 more
08:48:35,515 http-127.0.0.1-8080-6 DEBUG [ResourceBean] Destructed
com.kennardconsulting.core.ejb.session.ResourceBean@11611dc
08:48:35,546 http-127.0.0.1-8080-6 DEBUG [ResourceBean] Constructed
com.kennardconsulting.core.ejb.session.ResourceBean@18227b1
08:48:35,546 http-127.0.0.1-8080-6 DEBUG [ResourceBean] Loading 'RKennard'...
08:48:35,546 http-127.0.0.1-8080-6 DEBUG [ResourceBean] JPA-QL: select a from Staff a
where a.name = :name (cacheable)
08:48:35,546 http-127.0.0.1-8080-6 DEBUG [ResourceBean] JPA-QL: name: 'RKennard'
08:48:35,546 http-127.0.0.1-8080-6 DEBUG [SQL] select staff0_.id as id1_,
staff0_1_.dateCreated as dateCrea2_1_, staff0_1_.dateUpdated as dateUpda3_1_,
staff0_1_.updatedBy as updatedBy1_, staff0_1_.version as version1_, staff0_1_.name as
name1_, staff0_1_.firstLoginDate as firstLog7_1_, staff0_1_.password as password1_,
staff0_.firstname as firstname43_, staff0_.surname as surname43_, staff0_.title as
title43_ from Staff staff0_ inner join Resource staff0_1_ on staff0_.id=staff0_1_.id where
staff0_1_.name=?
08:48:35,546 http-127.0.0.1-8080-6 DEBUG [ResourceBean] ...loaded 'RKennard'
08:48:35,562 http-127.0.0.1-8080-6 DEBUG [ResourceBean] Loading
'4028818126273479012627c550d60004' (Staff)...
08:48:35,562 http-127.0.0.1-8080-6 DEBUG [SQL] select staff0_.id as id1_0_,
staff0_1_.dateCreated as dateCrea2_1_0_, staff0_1_.dateUpdated as dateUpda3_1_0_,
staff0_1_.updatedBy as updatedBy1_0_, staff0_1_.version as version1_0_, staff0_1_.name as
name1_0_, staff0_1_.firstLoginDate as firstLog7_1_0_, staff0_1_.password as password1_0_,
staff0_.firstname as firstname43_0_, staff0_.surname as surname43_0_, staff0_.title as
title43_0_ from Staff staff0_ inner join Resource staff0_1_ on staff0_.id=staff0_1_.id
where staff0_.id=?
08:48:35,562 http-127.0.0.1-8080-6 DEBUG [ResourceBean] ...loaded
'4028818126273479012627c550d60004' (_/>%ü'"&<_
<noo>Admin)
08:48:35,562 http-127.0.0.1-8080-6 DEBUG [CoreFacesUtils] FacesError:
javax.faces.FacesException: #{staff.delete}: java.lang.RuntimeException:
javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
at
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
at
com.kennardconsulting.core.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:120)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:324)
at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:299)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:256)
at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:469)
at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.kennardconsulting.core.servlet.EjbRemoveFilter.doFilter(EjbRemoveFilter.java:44)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.el.EvaluationException: java.lang.RuntimeException:
javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
at
javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102)
at
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
... 41 more
Caused by: java.lang.RuntimeException: javax.ejb.EJBTransactionRolledbackException:
Transaction rolled back
at
com.kennardconsulting.core.faces.controller.PersistentEntityController.delete(PersistentEntityController.java:275)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstValue.invoke(AstValue.java:170)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at
javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
... 42 more
Caused by: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleEndTransactionException(Ejb3TxPolicy.java:54)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:176)
at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:216)
at
org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
at
org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
at $Proxy354.delete(Unknown Source)
at
com.kennardconsulting.core.faces.controller.PersistentEntityController.delete(PersistentEntityController.java:259)
... 49 more
Caused by: javax.transaction.RollbackException:
[com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted]
[com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Could not commit
transaction.
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1435)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:170)
... 72 more
Caused by: java.lang.Throwable: setRollbackOnly called from:
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:392)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.setRollbackOnly(BaseTransaction.java:195)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.setRollbackOnly(BaseTransactionManagerDelegate.java:123)
at
org.hibernate.ejb.AbstractEntityManagerImpl.markAsRollback(AbstractEntityManagerImpl.java:421)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:576)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at
org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:513)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1423)
... 75 more
---
You can see in this log that:
1. at 08:48:35,468 I try to delete a database row that has a foreign key constraint.
2. at 08:48:35,484 Hibernate raises a ConstraintViolationException, which gets logged
3. at 08:48:35,562 an Exception reaches the Java Server Faces UI. It contains a
javax.ejb.EJBTransactionRolledbackException, but the stack trace stops at
'setRollbackOnly called from:'
So the rollback exception does not include the original ConstraintViolationException root
cause, which is what JBTM-66 was asking for. Perhaps I didn't ask for it very well,
for which I apologise.
Not including the root cause makes it difficult for UIs to display user-friendly error
messages. All I can say is 'transaction error'. If I had the root cause I could
say 'database error', or better yet 'item is relied upon by other items'.
I agree crossing JVM boundaries is a whole other problem, but that is not my use case.
Thanks for your help,
Richard.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:19 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Bozhidar Batsov commented on JBTM-575:
--------------------------------------
Apart from the different JVMs my problem happens to be exactly the same - in fact I first
noticed it when trying to delete a database row that has a foreign key constraint... Since
this used to work(there were the proper causes in the exception received in the client) in
JBoss 4.2.2 and since my client has hibernate and the mysql connector in its classpath
I'm fairly certain that your and mine problem are related and most probably the
same...
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:48 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
Bozhidar: I agree with your assessment.
Jonathan: over to you :)
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:02 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.setRollbackOnly(BaseTransactionManagerDelegate.java:123)
at
org.hibernate.ejb.AbstractEntityManagerImpl.markAsRollback(AbstractEntityManagerImpl.java:421)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:576)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at
org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:513)
What's key here is that, from the transaction manager's perspective, the
setRollbackOnly call precedes the exception - hibernate sets the tx to rollback before
throwing the exception. So, the setRollbackOnly call IS the root cause of the transaction
rolling back. JBTM-66 is not only present but functioning exactly as designed. As
mentioned in the forum thread, this is arguably misuse of the api by hibernate.
Of the alternatives proposed in the forum thread, chaining the deferredThrowable to the
rollbackOnly trace won't work, as there is no deferredThrowable at the point in time
that the setRollbackOnly call is made. So the only viable alternative seems to be using
the deferredThrowable as the initCause of the rollback in preference to the
rollbackOnlyCallerStackTrace in cases where both are available. Will that meet your
needs?
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:10 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Bozhidar Batsov commented on JBTM-575:
--------------------------------------
I think so.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:10 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Armin Haaf commented on JBTM-575:
---------------------------------
thats a viable solution for us. We should be able to get the root cause of the problem and
with your suggestion we could get it
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:29 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
Jonathan,
Brilliant. As long as I can navigate the stack trace from the
javax.ejb.EJBTransactionRolledbackException to the
MySQLIntegrityConstraintViolationException (or at least the ConstraintViolationException)
that would be awesome.
I am happy to be the guinea pig and test this if you can work up a JAR for JBoss AS
5.1.0.
Regards,
Richard.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:39 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
Right, I think I get it now. You basically want me to put in a workaround to resequence
the events back into causal order after hibernate has messed them up. I'm not going to
do that, because it will have the side effect of breaking reporting of e.g.
setRollbackOnly();
// time passes
// something unrelated goes wrong
cases which are currently correct and will become misleading if the 'something
unrelated' is made to appear as being the root cause of a rollbackOnly that actually
occurred before it.
Your best bet as a workaround for this specific scenario, unless you fancy persuading
hibernate to stop messing with causality, is probably to call the session flush directly
rather than relying on the beforeCompletion to do it. That should allow you to catch and
process the exception in your own code rather than having to mess with the
rollback.initCause.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:29 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
Jonathan,
Actually I have no problem asking Hibernate to stop messing with causality, if that is
what is happening. Perhaps this broke in JBoss 5.1.0 not because of a JBTM change but
because of a Hibernate change?
Could you please tell me which classes (even line numbers?) are suspect within the
Hibernate code, and I will raise a JIRA with that team.
Regards,
Richard.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:37 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Bozhidar Batsov commented on JBTM-575:
--------------------------------------
Johathan, can I ask you another question on a related topic(one that does not involve the
client at all).
If a business method in EJB session bean throws a RuntimeException in the JBoss log I see
only this line:
11:32:12,550 ERROR [TxPolicy] javax.ejb.EJBTransactionRolledbackException
No cause, no message, no nothing - the RuntimeException is however successfully relayed to
the client, but I remember that in older JBoss version I used to
get I full stack trace with the javax.ejb.EJBTransactionRolledbackException. What might be
causing this problem?
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:43 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
As we don't seem to be getting anywhere here, I have re-raised this with the Hibernate
team: https://jira.jboss.org/jira/browse/HIBERNATE-122
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:41 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Steve Ebersole commented on JBTM-575:
-------------------------------------
I have to jump in here. Hibernate has not "messed" anything up. Yes I am
biased ;)
My understanding of setRollbackOnly (and the understanding of many many others) is that is
merely provides a fail-safe to ensure the transaction is not allowed to commit.
This is a pretty standard JTA usage pattern in case of error. In fact one now even
mandated by JPA2.
If y'all deem that you'd prefer to not have JBTM work with any JPA2 provider then
that is obviously your call. But I'd humbly suggest that you should be able to back
this up with relevant sections from the JTA specification. Either JPA is violating the
JTA spec or JBTM needs to support this IMHO.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:36 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Ali Lahijani commented on JBTM-575:
-----------------------------------
It is very unfortunate that a adding a useful piece of debug information has caused such a
problematic regression. But as I understand, there as a really simple solution to this:
just make _theTransaction.getDeferredThrowable() take precedence over
_rollbackOnlyCallerStacktrace as the cause of the RollbackException.
The JPA spec states this under 5.9.2 Provider Responsibilities:
"When the provider throws an exception defined to cause transaction rollback, the
provider
must mark the transaction for rollback."
This is what the Hibernate guys quote when they state that they are just implementing what
the spec says. First mark the transaction for rollback and then throw the exception. I am
not aware of what the JTA spec mandates for a situation when both setRollbackOnly is
called on the TransactionManager and an exception is also thrown by a beforeCompletion()
method. The two events may be related (as in JPA) or completely unrelated. But since the
exception chaining mechanism also allows one cause for an exception, we need to decide
when we have them both.
In any case, the exception from the user code is evidently more eligible as the cause of
the RollbackException, rather than the synthetic Throwable created in setRollbackOnly()
because most likely it contains business information, thing like validation messages and
Hibernate consistency errors which are relevant to the user and indeed many apps
(including ours) rely on this information for their application logic. After all,
setRollbackOnly having been called is mostly treated like a booelan condition in JTA
spec.
Let me emphasize the importance of this. _theTransaction.getDeferredThrowable() should
never be ignored when it contains information, and that information should be carried over
to the cause chain of the RollbackException. However, when it is null and we are aborting,
then someone must have called TransactionManager.setRollbackOnly(), so it will be helpful
for debugging purposes to let them know who called that method.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:52 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/jira/browse/JBTM-575?page=com.atlassian.jira.plugi...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
Jonathan,
As you asked, I asked someone from the Hibernate team (Steve Ebersole) about casuality.
Steve has since responded, as have a couple other people. What is our next step to getting
this resolved?
Regards,
Richard.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:54 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Mark Little commented on JBTM-575:
----------------------------------
"First mark the transaction for rollback and then throw the exception. I am not aware
of what the JTA spec mandates for a situation when both setRollbackOnly is called on the
TransactionManager and an exception is also thrown by a beforeCompletion() method."
It can't happen. If you call setRollbackOnly then the two-phase commit protocol
doesn't get triggered, so beforeCompletion won't be called.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:16 p.m.
New subject: [JBoss JIRA] Assigned: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Mark Little reassigned JBTM-575:
--------------------------------
Assignee: Jonathan Halliday
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:57 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Ali Lahijani commented on JBTM-575:
-----------------------------------
It does happen, because the application code can still call Transaction.setRollbackOnly()
after the two-phase commit has been started. As you can see in the above stack-trace,
Hibernate calls setRollbackOnly() within a Synchronization.beforeCompletion() callback.
I'm copying it here:
Caused by: java.lang.Throwable: setRollbackOnly called from:
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:392)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.setRollbackOnly(BaseTransaction.java:195)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.setRollbackOnly(BaseTransactionManagerDelegate.java:123)
at
org.hibernate.ejb.AbstractEntityManagerImpl.markAsRollback(AbstractEntityManagerImpl.java:421)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:576)
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at
org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:513)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1423)
... 75 more
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:22 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Steve Ebersole commented on JBTM-575:
-------------------------------------
Right. Sometimes the trouble is triggered by the processing done in beforeCompletion(),
especially in cases where it triggers a flush.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:53 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Mark Little edited comment on JBTM-575 at 9/14/10 5:53 AM:
-----------------------------------------------------------
You guys do realise that calling setRollbackOnly in beforeCompletion isn't necessary:
throw any exception from within beforeCompletion and the transaction must abort anyway.
was (Author: mark.little(a)jboss.com):
You guys do realise that calling setRollbackOnly in beforeCompletion isn't
necessary: throw any exception and the transaction must abort anyway.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:53 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Mark Little commented on JBTM-575:
----------------------------------
You guys do realise that calling setRollbackOnly in beforeCompletion isn't necessary:
throw any exception and the transaction must abort anyway.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:55 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
Mark - That's incorrect - it is mandated by various specs.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:05 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
ok, let me clarify that - the specs mandates calling setRolllbackOnly and make no specific
provision for being inside beforeCompletion. It's possible to comply with the spirit
of the spec (i.e. 'ensure tx rollback') whilst violating its letter, by throwing
an exception instead, if you can detect you are inside beforeCompletion. That's tricky
at best
My current thinking on this is to solve the problem from the other side: if the tx manager
gets a setRollbackOnly call and exception whilst processing beforeCompletion, it should
have the option to reorder them on the basis that the setRollbackOnly call is likely a
result of the exception, despite the tx manager actually seeing the setRollbackOnly before
the exception. If the API supported setRollbackOnly(Throwable cause) we'd be better
off, but the real world just aint that simple.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:10 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Jonathan Halliday commented on JBTM-575:
----------------------------------------
Right you 'orrible lot, here is the plan:
if setRollbackOnly() is called before commit() then the initCause is 'setRollbackOnly
called from...' regardless of anything that may go wrong during the commit.
beforeCompletions (e.g. hibernate session flush) won't be called anyhow.
otherwise if getDeferredThrowable is non null then the initCause is the deferredThrowable.
Even if setRollbackOnly is also called before the exception is received. (Ick. I'm not
happy, but I'm outnumbered by pragmatists.)
otherwise if setRollbackOnly was called then it is the root cause. This covers the case
where a beforeCompletion calls setRollbackOnly but does not throw an exception.
If you're going to moan and whine now would be a good time...
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:56 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
Jonathan,
Kudos for the 'orrible lot reference :)
I, for one, would be happy with this solution.
Regards,
Richard.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:25 a.m.
New subject: [JBoss JIRA] Updated: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Jonathan Halliday updated JBTM-575:
-----------------------------------
Fix Version/s: 4.14.0
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:15 a.m.
New subject: [JBoss JIRA] Closed: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Jonathan Halliday closed JBTM-575.
----------------------------------
Resolution: Done
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:40 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Misty Stanley-Jones commented on JBTM-575:
------------------------------------------
Was this fixed or not? I can't tell from the JIRA or the forum post. Assuming that it
was, I will write this release note:
Cause: In ArjunaCore which was included in JBoss Application Server 4.2 and previous, when
a transaction rolled back, the <systemitem>RollbackException</systemitem>
included the root cause of the exception. In JBoss Application Server 5.1, the exception
no longer included this information, even though the information could still be found in a
different area of the log file.
Consequence: Developers who relied on the information included in the
<systemitem>RollbackException</systemitem> in the older versions of JBoss
Application Server found that their applications no longer worked as expected.
Fix: The debugging information has been put back into the exception, so that it works as
it did previously.
Result: Developers can once again write code to take advantage of the debugging
information found in the <systemitem>RollbackException</systemitem>.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:04 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Misty Stanley-Jones commented on JBTM-575:
------------------------------------------
Whoops, this was a JIRA fail. I will rewrite with the contents of
https://jira.jboss.org/browse/JBTM-575?focusedCommentId=12556090&page...:
Cause: In ArjunaCore which was included in JBoss Application Server 4.2 and previous, when
a transaction rolled back, the <systemitem>RollbackException</systemitem>
included the root cause of the exception, in the form of the class which caused it. In
JBoss Application Server 5.1, the exception no longer included this information, even
though the information can still be found in a different area of the log file.
Consequence: Developers who relied on the information included in the
<systemitem>RollbackException</systemitem> in the older versions of JBoss
Application Server found that their applications no longer worked as expected.
Fix: The debugging information has been put back into the exception, so that it works as
it did previously. The following algorithm is used:
1. If setRollbackOnly() is called before commit(), the initCause is 'setRollbackOnly
called from...' regardless of anything that may go wrong during the commit.
beforeCompletions are not called.
2. If getDeferredThrowable is not null, the initCause is the deferredThrowable, Even if
setRollbackOnly is also called before the exception is received.
3. If setRollbackOnly was called, it is the root cause. This covers the case where a
beforeCompletion calls setRollbackOnly but does not throw an exception.
Result: The root cause of the exception is once again included, so developers can once
again write code to take advantage of the debugging information found in the
<systemitem>RollbackException</systemitem>.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:27 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-575) javax.transaction.RollbackException root cause
[
https://jira.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.sys...
]
Richard Kennard commented on JBTM-575:
--------------------------------------
I have not had chance yet to try this fix (I assume it will be in JBoss AS 6?) but I would
like to thank everyone for their hard work on addressing it, especially as it was an
unpopular request and 'went against the grain' of people's preferred
architecture.
I look forward to my code saying sensible error messages once again!
Richard.
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:57 p.m.
New subject: [JBoss JIRA] Reopened: (JBTM-575) javax.transaction.RollbackException root cause
[
https://issues.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.s...
]
Jonathan Halliday reopened JBTM-575:
------------------------------------
reopening for backport
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://issues.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:59 p.m.
New subject: [JBoss JIRA] Updated: (JBTM-575) javax.transaction.RollbackException root cause
[
https://issues.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.s...
]
Jonathan Halliday updated JBTM-575:
-----------------------------------
Fix Version/s: 4.6.1.CP12
JBoss Forum Reference: http://community.jboss.org/thread/145623?tstart=0 (was:
http://community.jboss.org/thread/145623?tstart=0)
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://issues.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.14.0, 4.6.1.CP12
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:01 p.m.
New subject: [JBoss JIRA] Closed: (JBTM-575) javax.transaction.RollbackException root cause
[
https://issues.jboss.org/browse/JBTM-575?page=com.atlassian.jira.plugin.s...
]
Jonathan Halliday closed JBTM-575.
----------------------------------
Resolution: Done
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://issues.jboss.org/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
Assignee: Jonathan Halliday
Fix For: 4.6.1.CP12, 4.14.0
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the
RollbackException included the root cause of the exception. This enhancement was
implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does
not affect manual debugging (the root cause is still logged higher up in the logs), but
makes it difficult for application code that relies on being able to unwrap the
RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4974
days inactive
5675
days old
jbossts-issues@lists.jboss.org
36 comments
8 participants
participants (8)
-
Ali Lahijani (JIRA) -
Armin Haaf (JIRA)
-
Bozhidar Batsov (JIRA)
-
Jonathan Halliday (JIRA)
-
Mark Little (JIRA)
-
Misty Stanley-Jones (JIRA)
-
Richard Kennard (JIRA)
-
Steve Ebersole (JIRA)