Refresh of an entity should clear its entries in the action queue

Description

We're using optimistic locking for some statistics entities and are doing re-tries on StaleObjectStateException by refreshing the entity and re-applying our update. However, this fails in the same way every time as the failed update lingers in the action queue and is flushed before the changed update.
Shouldn't/Couldn't refresh clear the action queue from actions of the given entity? As it is now it's quite nasty as you think you know what the instance looks like, but there is a hidden update just waiting for a flush.

Our work-around is to cast Session to EventSource and clear the action queue ourselves (we pre-flush the session before the optimistic locking update to ensure the failed update is the only one queued), but that feels a bit like a hack.

Environment

JBoss 4.2.3
Spring 2.5.5

Activity

Show:
Strong Liu
October 12, 2011, 11:08 AM

http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/transactions.html#transactions-demarcation-exceptions

If the Session throws an exception, including any SQLException, immediately rollback the database transaction, call Session.close() and discard the Session instance. Certain methods of Session will not leave the session in a consistent state. No exception thrown by Hibernate can be treated as recoverable. Ensure that the Session will be closed by calling close() in a finally block.

Lukasz Antoniak
October 12, 2011, 12:15 PM

Thanks for explanation. Issue can be closed from my point of view.

Jonas Olsson
October 12, 2011, 12:29 PM

I've also read that documentation and I don't accept it as an excuse to not support this. However, considering that's an "assumption" in Hibernate, what I'm asking for could very well be considered too much effort/risk (and that's an excuse I accept).
It just seems a bit weak that optimistic locking automatically pushes all retry mechanisms to outside the ongoing transaction/session, probably into code that's not necessarily aware of optimistic locking at all.

Strong Liu
October 12, 2011, 2:57 PM

Jonas,

no, that's is not 'too much effort/risk' but design.
that's how we design Session, it is a light weight Object, and should be throw away once there is a hibernate exception thrown.

Brett Meyer
March 7, 2014, 5:31 PM

Bulk closing rejected tickets in "resolved" state.

Assignee

Strong Liu

Reporter

Jonas Olsson

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure