JBossDeveloper

We are having the same problem. Has anyone tried other options like

optimistic-lock="false"

on some of the relationships between token and the other tables? The children relationship looks suspect in that is a child Token gets removed or added, the version of the parent Token is incremented. This could possibly cause lots of StaleObjects during transitions in sub processes say if I understand the data model correctly.

Also, has anyone tried

<class name="Token" table="TOKEN" optimistic-lock="all">

or

<class name="Token" table="TOKEN" optimistic-lock="dirty">

thus removing the version column altogether and using the values of columns in memory to detect a clash?

The Hibernate docs say using a "version" column is preferred but these other strategies may solve the problem if not elegantly.

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 */

@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.

@erciped:

No, and I can't (at least not against a real Oracle or PostgreSQL). I agree that the issue seems to be in that direction. Can you give it a try?

Thanks for reporting back... for me it would not be the solution, but we could chance the default for oracle to 'upgrade' if de process is parsed. Otoh, maybe just a 'known-issue' regarding these specific processdefinition cases would be better. I hate putting db/as/jdk specific code in my classes

Yes, I've seen it. I'll respond later today