[hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1989) Deleted object remains referenced in 2nd level cache collections

[Max Rydahl Andersen (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989?page=all ]
     
Max Rydahl Andersen closed HHH-1989:
------------------------------------

    Resolution: Rejected

"Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. "

So you don't cleanup and maintain your objectgraph ? How should hibernate then ensure the consistency ?

In any respect take a look at the not-found attribute which is there to handle broken datamodels and/or objectgraphs.

> Deleted object remains referenced in 2nd level cache collections
> ----------------------------------------------------------------
>
>          Key: HHH-1989
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0.cr2
>  Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3
>     Reporter: Justin Haddad

>
>
> This problem seems identical to issue NH-678.  I have enabled caching for an one-to-many association.  I use Ehcache.  I have a test in which I load the parent object along with its collection.  Both the parent and the collection wind up in the 2nd level cache.  I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself.   After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object):
> aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102]
> 	at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372)
> 	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128)
> 	at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178)
> 	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86)
> 	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
> 	at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839)
> 	at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
> 	at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
> 	at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101)
> 	at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
> 	at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
> 	at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
> 	at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1705)
> (continues on)
> I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira