Bug 889091

Summary:	Commit per node transition and recovery support
Product:	[JBoss] JBoss Enterprise BRMS Platform 5	Reporter:	Toshiya Kobayashi <tkobayas>
Component:	jBPM 5	Assignee:	Kris Verlaenen <kverlaen>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	BRMS 5.3.1	CC:	althomas
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	958386 (view as bug list)		Environment:
Last Closed:		Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Toshiya Kobayashi 2012-12-20 08:10:47 UTC

Description of problem:

a) Being able to commit a transaction per node transition regardless of synchronous or asynchronous. Hopefully by configuration basis (not additional development effort by users)

b) Recovery support (continuing process instance execution) after JVM reboot (including JVM crash case). The key point is less development effort by users

Comment 1 JBoss JIRA Server 2013-01-07 02:48:37 UTC

Toshiya Kobayashi <tkobayas> made a comment on jira JBPM-3889

Attached an example, which demonstrates that commit per node transition with BRMS 5.3.0. The customer doesn't feel nice with it because it requires development on their side and more development if they consider recovery which is described in (b).

FYI : "jBPM5 Developer Guide" Chapter 11 suggests persisting BusinessEntity object to hold ksessionId/processInstanceId/workItemId relation in WorkItemHandler for async WorkItem but it has the same concern... Isn't it too much effort on application side? Can jBPM provide some help out-of-box?