Red Hat Bugzilla – Bug 1006922
JPAWorkingMemoryDbLogger for abortProcessInstance or signalEvent causes PersistenceException
Last modified: 2013-09-13 02:02:34 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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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.
Created attachment 796680 [details]
Attached AbortProcessCommitTest that fails at ksession.abortProcessInstance(processId); .... the full stacktraces for abortProcessInstance and signalEvent will follow.
Created attachment 796682 [details]
Stacktrace for abortProcessInstance
Created attachment 796683 [details]
Stacktrace for signalEvent
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.
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)
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.
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?