[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5678) Entity Remains in L2 Cache After StaleObjectStateException
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5678?page=c...
]
j nadler commented on HHH-5678:
-------------------------------
We were able to fix this by changing EntityUpdateAction.java starting at approx line 115:
if ( !veto ) {
try {
persister.update(
id,
state,
dirtyFields,
hasDirtyCollection,
previousState,
previousVersion,
instance,
rowId,
session
);
} catch (StaleObjectStateException e) {
if (persister.hasCache()) {
persister.getCacheAccessStrategy().remove( ck );
}
throw e;
}
}
Entity Remains in L2 Cache After StaleObjectStateException
----------------------------------------------------------
Key: HHH-5678
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5678
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.5.6
Environment: Hibernate 3.5.6, problem has been reproduced on multiple databases
(MySQL 5.1, Oracle 11g, SQL Server 2005, SQL Server 2008)
Reporter: j nadler
Priority: Critical
StaleObjectStateExceptions will happen, and the optimistic locking mechanism is a great
benefit overall for our application. Unfortunately after this occurs, the invalid
(version mismatch with DB) version of the entity can get 'stuck' in the L2 cache.
We could write application level code to handle this, but it's ugly and intrusive.
The best solution is for Hibernate Core to evict from L2 whenever a
StaleObjectStateException is thrown.
If you didn't want to change current behavior this could be configurable I guess.
The default behavior should probably be 'evict'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira