[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5944) Refresh of an entity should clear its entries in the action queue

[Jonas Olsson (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44007#comment-44007 ] 

Jonas Olsson commented on HHH-5944:
-----------------------------------

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.

> Refresh of an entity should clear its entries in the action queue
> -----------------------------------------------------------------
>
>                 Key: HHH-5944
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5944
>             Project: Hibernate Core
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 3.3.2
>         Environment: JBoss 4.2.3
> Spring 2.5.5
>            Reporter: Jonas Olsson
>            Assignee: Strong Liu
>
> 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. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira