See attached project to reproduce. In short, create an object, update it, and perform a second get on that object (caching is on yes), in that second get in the hibernate trace logging "cached item was locked" is seen. The operations are done serially and not in parallel, so the cache item should not still be locked as in http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/cache/ReadWriteCache.java?r=HEAD there is a
finally {
cache.unlock(key);
}
Example of the logs:
06-22 13:36:17,416 TRACE [org.hibernate.event.def.DefaultLoadEventListener] loading entity: [org.domain.seam202fp.entity.Parent#1]
2010-06-22 13:36:17,416 TRACE [org.hibernate.event.def.DefaultLoadEventListener] attempting to resolve: [org.domain.seam202fp.entity.Parent#1]
2010-06-22 13:36:17,416 TRACE [org.hibernate.cache.ReadWriteCache] Cache lookup: org.domain.seam202fp.entity.Parent#1
2010-06-22 13:36:17,416 TRACE [org.hibernate.cache.ReadWriteCache] Cached item was locked: org.domain.seam202fp.entity.Parent#1
2010-06-22 13:36:17,416 TRACE [org.hibernate.event.def.DefaultLoadEventListener] object not resolved in any cache: [org.domain.seam202fp.entity.Parent#1]
2010-06-22 13:36:17,416 TRACE [org.hibernate.persister.entity.AbstractEntityPersister] Fetching entity: [org.domain.seam202fp.entity.Parent#1]
2010-06-22 13:36:17,416 DEBUG [org.hibernate.loader.Loader] loading entity: [org.domain.seam202fp.entity.Parent#1]
Hibernate 3.3
if dynamic update be disabled, then the second get will hit cache
note: if using dynamic update but without optimistic-locking(version or timestamp) enabled on a detached entity, then the invalidation mechanism will ensure the second get go to database, and because of timestamps it will replace the data in cache on read.
so, this is expected.
Samuel,
it would better that link the product issue back to the project issue
Bulk closing stale resolved issues