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.
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.
Thanks for explanation. Issue can be closed from my point of view.
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.
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.
Bulk closing rejected tickets in "resolved" state.