StaleObjectStateException with LockType OPTIMISTIC_FORCE_INCREMENT and remove Entity


I’m using Hibernate 4.2.21 and I use OPTIMISTIC FORCE INCREMENT to update version of parent entities in 1-to-many relations if the children get updated. This works fine unless the parent is removed in the same transaction.
Actually this can be reduced to a very simple example:

EntityManager em = ...
MyVersionedEntity entity = ...
em.lock (entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT)
em.remove (entity)
em.getTransaction ().commit()

always gives the following exception:

Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.syncrotess.gen.model.jpa.MyVersionedEntity#4621066252771655745]
	at org.hibernate.persister.entity.AbstractEntityPersister.forceVersionIncrement(
	at org.hibernate.action.internal.EntityIncrementVersionProcess.doBeforeTransactionCompletion(
	at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(
	at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(
	at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(
	at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(
	at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(
	at org.hibernate.ejb.TransactionImpl.commit(

The underlying issue is that the EntityIncrementVersionProcess trie to update the version though the entity is deleted. It works if I switch to PESSIMISTIC_FORCE_INCREMENT but that is hard to achieve in my concrete scenario, because at the point where I set the lock I cannot know if the entity is being removed later on and upgrading the OPTIMISTIC_FORCE_INCREMENT to a PESSIMISTIC_FORCE_INCREMENT does not work, i.e. Hibernate still tries to update the version on commit.

It is caused/fixed by

@gbadner Is it safe to pick into 4.2 branch? Is this branch still maintained or do I have to fork and build it myself?

Hibernate ORM 4.2 is no longer maintained. I believe it should would be OK to cherry-pick the fix back to 4.2, but I haven’t tried it myself so I can’t say for sure.

Thank you, I tried it and it worked.
One question though, we have been using 4.2.21.FINAL because it has been the last 4.2.x release published to Maven Central. If I take a look at GitHub I find further release until 4.2.27.Final, where are those published?