Bug 743417

Summary: use separate JPA EntityManagerFactory for jbpm-bam
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Jeffrey Bride <jbride2001>
Component: jBPM 5Assignee: Kris Verlaenen <kverlaen>
Status: ASSIGNED --- QA Contact: Radovan Synek <rsynek>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: BRMS 5.3.0.GA   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jeffrey Bride 2011-10-04 20:27:16 UTC 
out-of-the-box, BRMS is configured with a single persistence.xml that bundles jbpm-bam with core jbpm5 SessionInfo, WorkItemInfo, and ProcessInstanceInfo.

since BAM is functionally different than core jbpm5, recommend that at a minimum, jbpm-bam be managed by a separate EntityManagerFactory.  

Doing so will necessitate a new extension of WorkingMemoryLogger.  Please see attachment for an example extension to WorkingMemoryLogger.
Comment 1 Jeff DeLong 2011-10-05 19:41:14 UTC 
Even better would be to send BAM "events" via JMS to another service that persists the BAM data. This (along with potentially other design changes) would allow BAM processing to be removed from the process runtime environment. Doing so would greatly reduce the impact on process instance creation, etc. and allow a BAM server to be more optimally configured.

Also, system configuration should allow BAM functionality to be turned off completely if the customer wishes to do so, thereby eliminating all BAM related load.
Comment 2 Jeff DeLong 2011-10-05 19:43:58 UTC 
I see Jeff B captured this last idea in 743419.
Comment 3 Kris Verlaenen 2012-01-02 18:04:58 UTC 
I'll look at supporting both use cases, where you can set an entity manager directly (when registering the listener), or you can just reuse the one in the environment (if none is provided).

Note that the BAM events already are implemented outside the core engine itself, the history logger is a normal listener that you need to register (and so you have no impact at all if you don't need BAM, just don't register the listener).