Bug 779497

Summary: JobExecutor doesn't roll back the transaction even if the action handler throws Exception
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Toshiya Kobayashi <tkobayas>
Component: JBPM - within SOA, JBPM - standaloneAssignee: Alejandro Guizar <alex.guizar>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 5.0.0 ER7CC: dlesage
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-1880
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: SOA-1880 Environment:
Last Closed: 2010-03-24 09:09:05 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.zip none

Description Toshiya Kobayashi 2010-01-26 00:37:07 UTC 
++ This bug is a clone of bug 779496 ++

Affects: Release Notes
Date of First Response: 2010-01-27 16:22:11
Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/379428
Workaround: Workaround Exists
Workaround Description: Call JbpmContext.setRollbackOnly() in the action handler
project_key: SOA

In case that Job execution of an async node is processed by JobExecutor, the transaction is not rolled back even if the action handler throws Exception/RuntimeException. The transaction is commtted and no retry happens. It looks inconsistent with docs:
http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.CP02/html-single/JBPM_Reference_Manual/index.html#jbpmsbuiltinasynchronousmessaging
============
If execution of a command message fails, the transaction will be rolled back. After that, a new transaction will be started that adds the error message to the message in the database. The command executor filters out all messages that contain an exception.
============

I've attatched a reproducer.
- unzip jobexecution.zip
- modify build.properties
- ant deploypar
- ant deploy
- ant ejbclient (or access jbpm-console to start process instance)
- access jbpm-console to check process instance's id which is created by the action handler (which should be rolled back)
Comment 1 Toshiya Kobayashi 2010-01-26 01:23:56 UTC 
Attachment: Added: jobexecution.zip
Comment 3 Toshiya Kobayashi 2010-01-26 01:48:36 UTC 
Link: Added: This issue depends JBPM-2767
Comment 4 Toshiya Kobayashi 2010-01-26 01:53:36 UTC 
Link: Removed: This issue depends JBPM-2767
Comment 5 Toshiya Kobayashi 2010-01-26 01:54:22 UTC 
Link: Added: This issue incorporates JBPM-2767
Comment 6 Toshiya Kobayashi 2010-01-26 01:55:41 UTC 
Link: Added: This issue related SOA-1882
Comment 7 Toshiya Kobayashi 2010-01-26 09:33:11 UTC 
added 5.0.0.ER7 as affects version
Comment 8 Alejandro Guizar 2010-01-27 21:22:10 UTC 
Link: Added: This issue incorporates JBPM-2691
Comment 9 Alejandro Guizar 2010-01-27 21:22:11 UTC 
JBPM-2767 is in effect a duplicate of JBPM-2691, incorporating the latter issue.
Comment 10 Anne-Louise Tangring 2010-02-25 19:39:34 UTC 
Approved for SOA 4.3 CP03. Please make sure it gets assigned to the appropriate person.
Comment 11 Alejandro Guizar 2010-03-05 19:14:44 UTC 
JBPM-2691 is resolved. SOA-P team, please close as appropriate.
Comment 12 David Le Sage 2010-03-22 23:02:33 UTC 
The following draft text has been added to the Resolved Issues section of the Release Notes:



SOA-1880 https://jira.jboss.org/jira/browse/JBPM-2767

   If an async node was being processed by the JobExecutor and the action handles threw an
   exception, the transition was committed. As a consequence, no attempt was made to re-process it.

   To fix this issue, JbpmContext.setRollbackOnly() is now called by the action handler.
   As a result, if an exception occurs during job execution, the exception is stored and the
   job is automatically reprocessed for a determined number of retries. (This number is set in
   jbpm.cfg.xm.)
Comment 13 Martin Vecera 2010-03-24 09:09:05 UTC 
Verified in 4.3.CP03 ER1