[JBoss jBPM] - Re: Problem with a decision node in a fork, join construct.
by kukeltje
@Jan,
Yes, the lock can be on the processdefinition. If it complaints and you have a reference to the xsd, remove that.... validating against the xsd does not work then. (also a jira issue might be created then for the xsd to be updated)
@Martin.. Yes, I'd like to but I get 403's when committing. Someone has to fix that and I don't know who (already informed Tom)
The generator type was just to see if postgress would work then and kind of confirm it has a releation to generated-id's (via sequences) or auto-increment one. It was never meant to be changed indefinately
On a sidenote, If I add the flush back in the code, my H2 oracle compatible db does not lead to any errors as without it I get a SOE
The strange thing is that UPGRADE and FORCE (the default if nothing is provided) are kind of similar for hibernate. FORCE also working for not versioned objects... strange. Maybe one of the JBoss Hibernate experts could have a look.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197225#4197225
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197225
15 years, 6 months
[JBoss jBPM] - Re: jBPM 3.3.0GA and Oracle causing StaleObjectStateExceptio
by jjrs
I have a similar problem, although in my case the nodes have async='true'.
The exception I get is
| org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#48]
| at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1769)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2412)
| at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2312)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2612)
| at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:96)
| at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
| 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:262)
| at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:218)
| at org.jbpm.svc.Services.close(Services.java:236)
| at org.jbpm.JbpmContext.close(JbpmContext.java:136)
| at org.jbpm.job.executor.JobExecutorThread.executeJob(JobExecutorThread.java:190)
| at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:60)
|
I have tried::
- all the possible isolation levels (as suggested in the forum).
- the different "lock" options in the join and in the fork.
- tried to put back the flush that Tom removed some time ago in the Join class.
- selected the correct hibernate dialect.
But I still have the same issue.
The StaleObjectStateException is making one of the nodes to be executed twice, but if you have a more complicated graph, it's making a part of the graph not to be executed at all.
Any idea about how to proceed ? I saw that the issue JBPM-1757 was Deferred to 3.3.2 planned for May 2009. Is there any way that we could get the Join and Fork with parallel processing of nodes (async=true) before?
Does anyone have a similar configuration running in Oracle with 3.3.0GA or is it something that simply is not working yet due to a regression error ?
I would really appreciate any help, as I have been investigating the issue, reading the forum entries, and trying different configurations for almost a week, and I am still not able to make it work.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197186#4197186
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197186
15 years, 6 months
[JBoss jBPM] - Re: Problem with a decision node in a fork, join construct.
by mputz
Ronald, thanks for the unit test. I executed it against mysql, postgres and oracle (the real ones and not just h2 in the different modes to be sure), and here is what I've found:
+ " <join name='join'>" /* the default: leads to StaleObjectStateException with Oracle and Postgres */
| //+ " <join name='join' lock='"+ LockMode.UPGRADE.toString() + "'>" /* works */
| //+ " <join name='join' lock='"+ LockMode.UPGRADE_NOWAIT.toString() + "'>" /* works */
| //+ " <join name='join' lock='"+ LockMode.NONE.toString() + "'>" /* works */
| //+ " <join name='join' lock='"+ LockMode.READ.toString() + "'>" /* works */
| //+ " <join name='join' lock='"+ LockMode.WRITE.toString() + "'>" /* invalid lock mode */
| //+ " <join name='join' lock='"+ LockMode.FORCE.toString() + "'>" /* StaleObjectStateException */
|
So, setting the LockMode seems to be a valid workaround to fix this on Oracle and Postgres.
Btw, I have also tried to change the generator type, but that didn't help (besides that this is not compatible to the various dbs).
Are you going to check in your unit test?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197119#4197119
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197119
15 years, 6 months