org.hibernate.HibernateException when doing GraphSession.sav

[wowfee]

I am getting the following exception when doing GraphSession.saveProcessInstance().

This problem makes jBPM completely ususable for us. Too bad. It otherwise seems like an OK project. But not worth much if you can't save workflows....

Is there any prognosis when a fix will be available? Or should I try a different workflow system?

Ralph Harnden, Chief Architect
Altierre Corporation

P.S. We are using jbpm-3.0.1 under jboss-4.0.2.

java.lang.RuntimeException: couldn't save process instance 'org.jbpm.graph.exe.ProcessInstance@b35031'

at org.jbpm.db.GraphSession.saveProcessInstance(GraphSession.java:209)

at com.altierre.service.aap.mdb.WDTBundleBaseMDB.onMessage(WDTBundleBaseMDB.java:138)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)

at org.jboss.invocation.Invocation.performCall(Invocation.java:345)

at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:475)

at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)

at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:87)

at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)

at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)

at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)

at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)

at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:94)

at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)

at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)

at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:389)

at org.jboss.ejb.Container.invoke(Container.java:873)

at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:1090)

at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1392)

at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)

at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:904)

at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:160)

at org.jboss.mq.SpySession.run(SpySession.java:333)

at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)

at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)

at java.lang.Thread.run(Thread.java:534)

Caused by: java.lang.RuntimeException: couldn't delete timers for process instance 'org.jbpm.graph.exe.ProcessInstance@b35031'

at org.jbpm.db.SchedulerSession.cancelTimersForProcessInstance(SchedulerSession.java:129)

at org.jbpm.db.SchedulerSession.saveTimers(SchedulerSession.java:79)

at org.jbpm.db.GraphSession.saveProcessInstance(GraphSession.java:205)

... 27 more

Caused by: org.hibernate.HibernateException: Found shared references to a collection

at org.hibernate.engine.Collections.processReachableCollection(Collections.java:130)

at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:37)

at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:104)

at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:64)

at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java:58)

at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:198)

at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:190)

at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:70)

at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:39)

at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:711)

at org.hibernate.impl.SessionImpl.prepareQueries(SessionImpl.java:895)

at org.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:885)

at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:865)

at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:89)

at org.jbpm.db.SchedulerSession.cancelTimersForProcessInstance(SchedulerSession.java:124)

... 29 more

[stembol]

I get the same exception when saving my process instance.

Could you please tell me more about those timers?

[wowfee]

I am not using any timers, and in fact the jbpm_timer table has no rows.
I tried commenting out the line in GraphSession.saveProcessInstance() that invokes SchedulerSession.cancelTimersForProcessInstance(), but I got another similar error ("Found shared references to a collection") elsewhere when GraphSession.saveProcessInstance() was invoked.

Also, I am not using any Collections in any variables in my ContextInstance, so the existing open bug describing this error is not correct.

As I said, not being able to save a ProcessInstance is a severity 1 bug because it makes jbpm completely unusable. I wonder if any of the jbpm developers are reading this newsgroup. Do they care that their product is unusable?

[wowfee]

BTW, the open bug that describes this issue is JBPM-343 http://jira.jboss.com/jira/browse/JBPM-343, but in my case there are no Collections being used as process variables. I do not believe this bug is characterized properly as being related to storing Collections as process variables.

[brittm]

wowfee, I've never had a problem saving my process instances. Could you post the code you're using to create and save?

-Britt

[aguizar]

There is a suite of 219 unit tests that asserts persistence is *usable*. Therefore, the main sources of database problems are 1) configuration and 2) user code. Bugs in the jBPM code base are a third possibility (we are human) but if it didn't work at all, nobody would use jBPM.

Please describe what database and driver are you using, as well as the persistent objects you are adding to jBPM (variable values, action handlers local to the process, etc) and we will be able to help you better.

[wowfee]

I am very glad (and relieved) to see that somebody out there is listening.

I understand that there are 219 unit tests that assert persistance is "*usable*". Perhaps the test suite is not complete?

I also understand that this may be my bug, and I will continue to work to isolate the problem. However, since there is an open issue in the jBPM JIRA that describes a similar problem, and since at least one other person has posted a response to this topic indicating that they have a similar problem, it is quite likely that this is a jBPM (or Hibernate) problem.

I removed all updates of variables in my ContextInstance, and do not see the problem anymore. I am only using variables of type long and byte array. It appears to me that once I save my process instance, I can no longer update context variables and save my process instance again.

I will test this some more and post a follow-up if I discovery anything else.

[aguizar]

So, saving the process instance succeeds the first time, but not after that? Issue 343 reports the same symptom.
I added a comment there that could be useful. You might want to see it.

[wowfee]

OK, I will try that.

Also, I changed my Decision and ActionHandler instances to get/set variables from the ExecutionContext consistently, and things seem to work now (even though I am doing the unnecessary saveProcessInstance()).

Previously, I had mixed using ExecutionContext and the ContextInstance returned by ExecutionContext::getContextInstance() to get/set variables. After the change, the problems went away. I do not know why.

I did notice that when I mixed use of ExecutionContext and ContextInstance to get/set variables, some of the rows in jbpm_variableinstance did not have a value for token_. That is what led me to make the changes I describe above.

Is use of the ContextInstance returned by ExecutionContext::getContextInstance() to get/set variables specific to the ProcessInstance invalid?

I am still getting transient variables from the ContextInstance obtained from ExecutionContext::getContextInstance(). I assume that the ContextInstance is scoped to the ProcessInstance. Please let me know if this is not correct.

[wowfee]

Great! No need to saveProcessInstance once it is saved!

I mentioned before that when I mixed use of ExecutionContext and ContextInstance to set/get variables, some of the rows in jbpm_variableinstance did not have values for token_. Those rows also did not have values for processinstance_ or tokenvariablemap_.

[aguizar]

From the source code of ExecutionContext:

public Object getVariable(String name) {
 return getContextInstance().getVariable(name, token);
 }

Accessing a variable in the execution context is roughly equivalent to accessing it in the context instance directly, except that the former way always uses the token reference in the execution context.

Perhaps there is some problem with the methods in ContextInstance that do not take a token (and implicitly act on the root token).

Transient variables are simply a non-persistent Map in the context instance. No rocket science. There should be no problem there.

[brittm]

I wouldn't say "there's no need to save a process instance once its saved." I've found that if I don't call graphSession.saveProcessInstance(pi) after operating on the process, I don't have logs of the action.

-Britt

[stembol]

I get the same exception when trying to save a variable of type java.util.TreeSet.
What's strange is that I can save it once and then the second time I get the exception.

The exception is thrown in GraphSession.saveProcessInstance() at the line jbpmSession.getSchedulerSession().saveTimers(processInstance);

I think we have different problems but the message is completely unclear.

I migrate from jbpm2 and was hoping jbpm3 was more robust.

[aguizar]

Certainly the message is unclear, because it is a problem that we are trying to characterize and solve. Can you post the code you use to save your variable?

[wowfee]

I am able to use jBPM now. Thanks so much for your help.

BTW, I am not storing any collections or maps in variables.