Bug 779498 (SOA-1881)

Summary: JbpmContext.setRollbackOnly() in Job execution leads to "JbpmException: cannot mark externally managed transaction for rollback" with JCA inflow message service
Product: [JBoss] JBoss Enterprise SOA Platform 4 Reporter: Toshiya Kobayashi <tkobayas>
Component: JBPM - within SOAAssignee: Kevin Conner <kevin.conner>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 4.3 CP02CC: dlesage
Target Milestone: ---   
Target Release: 4.3 CP04 ER1   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-1881
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-24 09:48:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Deadline: 2010-03-08   
Attachments:
Description Flags
jobexecution-rollback.zip none

Description Toshiya Kobayashi 2010-01-26 01:01:10 UTC
Affects: Release Notes
Date of First Response: 2010-01-26 01:57:20
Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/379428
project_key: SOA

In case that Job execution of an async node is processed by ESB's JCA inflow message service, if you call jbpmContext.setRollbackOnly() in the action handler, the Exception below will be thrown:

19:11:51,045 ERROR [JmsServerSession] Unexpected error delivering message delegator->JBossMessage[5177979334393866]:PERSISTENT, deliveryId=1
org.jbpm.JbpmException: cannot mark externally managed transaction for rollback
at org.jbpm.persistence.db.DbPersistenceService.endTransaction(DbPersistenceService.java:129)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:201)
at org.jbpm.svc.Services.close(Services.java:247)
at org.jbpm.JbpmContext.close(JbpmContext.java:131)
at org.jboss.soa.esb.services.jbpm.integration.command.AbstractMessageListener.onMessage(AbstractMessageListener.java:80)
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.jboss.internal.soa.esb.dependencies.JCAInflowAdapter$1.invoke(JCAInflowAdapter.java:276)
at org.jboss.soa.esb.listeners.jca.EndpointProxy.delivery(EndpointProxy.java:242)
at org.jboss.soa.esb.listeners.jca.EndpointProxy.invoke(EndpointProxy.java:145)
at $Proxy92.onMessage(Unknown Source)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
at org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect16.invoke(SessionAspect16.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$run_N8003352271541955702.invokeNext(ClientSessionDelegate$run_N8003352271541955702.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$run_N8003352271541955702.invokeNext(ClientSessionDelegate$run_N8003352271541955702.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:237)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:213)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756)
at java.lang.Thread.run(Thread.java:619)

Actually, this causes rollback. But this looks messy on the console (stacktrace etc) so it's better to explicitly handle the rollback rather than forcing it as a side effect of invoking the jBPM context close().

Comment 1 Toshiya Kobayashi 2010-01-26 01:28:44 UTC
I've attatched a reproducer.
- unzip jobexecution-rollback.zip
- modify build.properties
- ant deploypar
- ant deploy
- ant ejbclient (or access jbpm-console to start process instance)

Comment 2 Toshiya Kobayashi 2010-01-26 01:28:44 UTC
Attachment: Added: jobexecution-rollback.zip


Comment 4 Toshiya Kobayashi 2010-01-26 01:56:26 UTC
Link: Added: This issue is related to SOA-1882


Comment 5 Toshiya Kobayashi 2010-01-26 02:31:41 UTC
Link: Added: This issue incorporates JBESB-3151


Comment 6 Kevin Conner 2010-01-26 06:57:20 UTC
This exception is thrown by the jBPM codebase but we can work around it in our message listener.

Comment 7 Toshiya Kobayashi 2010-01-26 09:31:55 UTC
added 5.0.0.ER7 as affects version

Comment 8 Kevin Conner 2010-01-26 16:13:07 UTC
Link: Added: This issue related SOA-1886


Comment 9 Kevin Conner 2010-01-27 09:45:05 UTC
Removing 5.0.0 ER7, see linked issue

Comment 10 Alejandro Guizar 2010-01-27 22:16:37 UTC
With SOA-1880/JBPM-2691, calling jbpmContext.setRollbackOnly() will no longer be necessary as a workaround to get the transaction rolled back, throwing any exception will be enough.

Throwing JbpmException: cannot mark externally managed transaction for rollback" is meant to let the caller know that jBPM cannot reliably pass the rollback request to a transaction it did not start itself. If the caller (in this case the ESB) is able to invoke jbpmContext.isRollbackOnly() and honor the rollback request, I could turn this exception into a warning log.

Comment 11 Kevin Conner 2010-01-28 10:05:31 UTC
We are now catching (and ignoring) all JbpmExceptions if the jBPM transaction service has it marked as rollback.

A better solution, from the perspective of jBPM, would be to handle this in JtaDbPersistenceService and invoke setRollbackOnly() on the encompassing transaction.

Comment 12 Anne-Louise Tangring 2010-02-25 19:41:38 UTC
Approved for SOA 4.3 CP03. Please make sure it gets assigned to the appropriate person.

Comment 13 Kevin Conner 2010-03-04 16:45:53 UTC
Link: Removed: This issue incorporates JBESB-3151 


Comment 14 Kevin Conner 2010-03-04 16:46:08 UTC
Link: Added: This issue depends JBESB-3151


Comment 15 Kevin Conner 2010-03-04 18:43:33 UTC
Updated in ESB branch, will be in next merge.

Comment 16 David Le Sage 2010-03-09 23:44:39 UTC
Draft text for Resolved Issues section of Release Notes states:



https://jira.jboss.org/jira/browse/JBESB-3151

    An org.jbpm.JbpmException: cannot mark externally managed transaction
    for rollback exception would occur if one called jbpmContext.setRollbackOnly() in the
    action handler whilst executing an async node via the Enterprise Service Bus' JCA Inflow
    Message Service.

    This exception was intended to let the caller know that jBPM cannot reliably pass the rollback
    request to a transaction it did not start itself. The software has been changed so that rather
    having it catch and ignore the JbpmExceptions that the transaction service has marked for
    rollback, they are instead handled by JtaDbPersistenceService. As a result of this change,
    setRollbackOnly() is now set only on the encompassing transaction. Hence, users are no
    longer faced with this exception.


Comment 17 Martin Vecera 2010-03-24 09:48:40 UTC
Verified in 4.3.CP03 ER1