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

[HG (JIRA)]

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

HG commented on HHH-1989:
-------------------------

Ideally a cleanup is best for a same transaction but in case of different parellel txns we have a problem.

not-found is good for delete in a different txns ( one can simply ignore it ).
And what about the inserts in different txns ?. do we have somthing like "check-for-new-relation=true"

> Deleted object remains referenced in 2nd level cache collections
> ----------------------------------------------------------------
>
>                 Key: HHH-1989
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: core
>    Affects 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