Bug 1241756

Summary: [GSS] (6.1.z) SingleSessionCommandService Interceptor stack is lost when rollback
Product: [Retired] JBoss BPMS Platform 6 Reporter: Toshiya Kobayashi <tkobayas>
Component: jBPM CoreAssignee: Alessandro Lazarotti <alazarot>
Status: CLOSED EOL QA Contact: Karel Suta <ksuta>
Severity: high Docs Contact:
Priority: high    
Version: 6.1.0CC: kverlaen, mbaluch, rsynek
Target Milestone: CR1   
Target Release: 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1241358 Environment:
Last Closed: 2020-03-27 20:08:34 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:
Embargoed:
Bug Depends On: 1241358    
Bug Blocks: 1249860    

Description Toshiya Kobayashi 2015-07-10 03:33:34 UTC
+++ This bug was initially created as a clone of Bug #1241358 +++

Description of problem:

RuntimeManager adds OptimisticLockRetryInterceptor and TransactionLockInterceptor on top of SingleSessionCommandService$TransactionInterceptor on KieSession initialization.

But once a transaction is rolled back in later process execution, SingleSessionCommandService.commandService is overwritten by new TransactionInterceptor(kContext) in initExistingKnowledgeSession() hence the Interceptor stack is lost.

How reproducible:

Once a process execution transaction is rolled back, always reproducible. It could be serious in case of Singleton strategy because an application keeps using the ksession alive.

Steps to Reproduce:
1. Going to send a pull request.

--- Additional comment from Toshiya Kobayashi on 2015-07-09 03:02:48 EDT ---

PR test case:
https://github.com/droolsjbpm/jbpm/pull/274

--- Additional comment from Toshiya Kobayashi on 2015-07-09 03:09:01 EDT ---

PR fix proposal:
https://github.com/droolsjbpm/drools/pull/458

Please review.

Comment 4 Karel Suta 2015-09-01 14:09:39 UTC
Verified in 6.1.3.