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

[Lukasz Antoniak (JIRA)]

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

Lukasz Antoniak commented on HHH-5944:
--------------------------------------

I don't know if I understood the forum topic in 100% and got the actual idea behind it. You suggest that after clearing action queue, it would be difficult to automatically retry saving changes. Am I right? See Rob Jellinghaus message posted on Mon Oct 17, 2005 6:47 pm. Is this the problematic line: {{session.refresh(objectToUpdate, LockMode.UPGRADE);}} ? If so, maybe we shall introduce a new LockMode/LockOptions that would clear action queue.
Sorry if I understood the forum topic incorrectly.

> 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