[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5944?page=c...
]
Strong Liu commented on HHH-5944:
---------------------------------
http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/transaction...
{quote}
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.
{quote}
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