all nodes in process and subprocesses are async.
14:49:16,412 JbpmJobExector:192.168.41.136:5 ERROR AbstractFlushingEventListener:108 - Could not synchronize database state with session org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.job.ExecuteNodeJob#12] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1765) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2407) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:253) at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:211) at org.jbpm.svc.Services.close(Services.java:222) at org.jbpm.JbpmContext.close(JbpmContext.java:139) at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:141) at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:56)
If you search for "StaleObjectStateException", you'll see other instances on this forum where it occurs after a fork. I don't know if it has the same cause as yours, because you didn't report any details about what you're doing. Unfortunately, no one bothered to follow up with a resolution or workaround, if one was found.
Also, see http://jira.jboss.com/jira/browse/JBPM-626. I'm not sure if it's relevant. It's reported in enough detail that you can probably tell. But again, unfortunately, no resolution or workaround was reported, if found.
I suggest that you prove to yourself that when your async events kick off, you're picking up the different node instances - not accidentally grabbing the same node instance, somehow.
Beyond that, sorry, I got nuthin'.
Please report what you find - this will be my problem soon, too!
seems like different threads try to work on the same job. in general concurrent execution is obviously not well tested. I hope our problem is limited to JobSession.getFirstAquireableJob...
ok, after synchronizing JobExecutorThread.acquireJobs() it seems to work
Can you be more specific?
I read your note as saying you changed the method signature to
protected synchronized Collection acquireJobs()
but that shouldn't help, because it will synchronize on the thread object. But this won't prevent other threads from hitting it at the same time. Unless acquireJobs() is being called from a subclass of JobExecutorThread, the only place it is called from is run(), so there's not even a remote possibility of a cross-thread invocation somehow.
If I understood you correctly, and this made the problem go away, I suspect it's just hiding for a while...
what I did as workaround is to synchronize on a static variable inside of acquireJobs(), this way locks are applied and concurrency works.
don't know if thats a good solution as I'm not much into jbpm internals...
well, next problem, on a join node all incoming branches try to update the parent token, which fails, I think I read about this already somewhere in the forum... altogether it seems that multithreaded async processes have never been tested...