Bug 1006922 - JPAWorkingMemoryDbLogger for abortProcessInstance or signalEvent causes PersistenceException
JPAWorkingMemoryDbLogger for abortProcessInstance or signalEvent causes Persi...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ER4
: 6.0.0
Assigned To: Maciej Swiderski
Ivo Bek
Depends On:
  Show dependency treegraph
Reported: 2013-09-11 09:57 EDT by Ivo Bek
Modified: 2013-09-13 02:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-13 02:02:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
AbortProcessCommitTest (1.78 KB, text/x-java)
2013-09-12 04:20 EDT, Ivo Bek
no flags Details
Stacktrace for abortProcessInstance (12.01 KB, text/plain)
2013-09-12 04:22 EDT, Ivo Bek
no flags Details
Stacktrace for signalEvent (14.35 KB, text/plain)
2013-09-12 04:23 EDT, Ivo Bek
no flags Details

  None (edit)
Description Ivo Bek 2013-09-11 09:57:30 EDT
Description of problem:

When I use abortProcessInstance or signalEvent method in ksession running with persistence, the PersistenceException is thrown with following statement.

javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not prepare statement
at org.jbpm.process.audit.JPAWorkingMemoryDbLogger.persist(JPAWorkingMemoryDbLogger.java:193)
	at org.jbpm.process.audit.JPAWorkingMemoryDbLogger.afterVariableChanged(JPAWorkingMemoryDbLogger.java:104)
	at org.drools.core.event.ProcessEventSupport.fireAfterVariableChanged(ProcessEventSupport.java:154)
	at org.jbpm.process.instance.context.variable.VariableScopeInstance.setVariable(VariableScopeInstance.java:79)
	at org.jbpm.workflow.instance.node.EventNodeInstance.signalEvent(EventNodeInstance.java:48)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 1 Maciej Swiderski 2013-09-11 11:40:26 EDT
Ivo, could you please provide little bit more information on the actual error, how to reproduce, complete stack trace, process used that causes this issue.

There are number of tests that already do what you described an none of them encounters such issues. So without more details it's difficult to proceed.
Comment 2 Ivo Bek 2013-09-12 04:20:09 EDT
Created attachment 796680 [details]

Attached AbortProcessCommitTest that fails at ksession.abortProcessInstance(processId); .... the full stacktraces for abortProcessInstance and signalEvent will follow.
Comment 3 Ivo Bek 2013-09-12 04:22:55 EDT
Created attachment 796682 [details]
Stacktrace for abortProcessInstance
Comment 4 Ivo Bek 2013-09-12 04:23:22 EDT
Created attachment 796683 [details]
Stacktrace for signalEvent
Comment 5 Maciej Swiderski 2013-09-12 04:36:46 EDT
Ivo, I believe the error you get here is caused by incorrect version of bitornix used. Please double check your project settings and make sure that:
- btm 2.x is excluded completely from the dependencies (class path)
- btm 3.0.0-SNAPSHOT is added as test dependency to the project

with that your tests should all work well.
Comment 6 Ivo Bek 2013-09-12 05:04:06 EDT
You are right once again :), thank you. It works now but I had to override the version in btm dependency from the bom, so it would be great to fix it in the bom. What do you think? (The managed version is 2.1.2 The artifact is managed in org.jboss.intregrationplatform:jboss-integration-platform-bom:6.0.0-redhat-1)
Comment 7 Maciej Swiderski 2013-09-12 06:20:00 EDT
Good to hear it does work.

I'll take that up for discussion how to proceed with btm version as it's still snapshot and we cannot have snapshot all the time.
Comment 8 Maciej Swiderski 2013-09-12 09:58:19 EDT
Ivo, there is another bz that deals with bitronix version https://bugzilla.redhat.com/show_bug.cgi?id=991777 so I think we can close this one and monitor the other, wdyt?

Note You need to log in before you can comment on or make changes to this bug.