[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2862) Collection is not associated with any session exception when doing an eager fetch on a non-unique collection.

Alexander Taggart (JIRA) noreply at atlassian.com
Sun Mar 9 22:42:33 EDT 2008


    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_29740 ] 

Alexander Taggart commented on HHH-2862:
----------------------------------------

I too have just run into a similar case whereby a many-to-many join annotation erroneously used non-unique column instead of the primary key.  The following hibernate code (from org.hibernate.engine.StatefulPersistenceContext) even comments on the issue:

	private void addCollection(PersistentCollection coll, CollectionEntry entry, Serializable key) {
		collectionEntries.put( coll, entry );
		CollectionKey collectionKey = new CollectionKey( entry.getLoadedPersister(), key, session.getEntityMode() );
		PersistentCollection old = ( PersistentCollection ) collectionsByKey.put( collectionKey, coll );
		if ( old != null ) {
			if ( old == coll ) {
				throw new AssertionFailure("bug adding collection twice");
			}
			// or should it actually throw an exception?
			old.unsetSession( session );
			collectionEntries.remove( old );
			// watch out for a case where old is still referenced
			// somewhere in the object graph! (which is a user error)
		}
	}

So, when encountering a case where the collection was associated with a previous entity, the previous entity's collection wrapper has its session invalidated.  The in-code comment is correct when it states the case "is a user error."  It would be great to get an exception reflecting that fact rather than what actually occurs:  nothing until I iterate over the collection and get a LazyInitializationException red herring.

> Collection is not associated with any session exception when doing an eager fetch on a non-unique collection.
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-2862
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2862
>             Project: Hibernate3
>          Issue Type: Bug
>         Environment: Hibernate 3.1.3 - Hibernate 3.2.5, HSQLDB, Java5
>            Reporter: Paul Andrews
>         Attachments: bug.zip, testcase.zip
>
>
> It is basically caused by having an eager collection where the key of the collection is not unique in the results.
> The code works as follows in CollectionType.getCollection():
>                                 ....
> 				persistenceContext.addUninitializedCollection( persister, collection, key );
> 	
> 				// some collections are not lazy:
> 				if ( initializeImmediately( entityMode ) ) {
> 					session.initializeCollection( collection, false );
> 				}
> 				else if ( !persister.isLazy() ) {
> 					persistenceContext.addNonLazyCollection( collection );
> 				}
> 	
> 				if ( hasHolder( entityMode ) ) {
> 					session.getPersistenceContext().addCollectionHolder( collection );
> 				}
> if persistenceContext.addUninitializedCollection() detects that the collection with the given key has already been added it clears the session on the old instance of the collection (sets it to null). However, that collection has already been added to the persistence context by an earlier call to this method. So later when StatefulPersistenceContext.initializeNonLazyCollections() is called it iterates through all of the collections in the persistence context (including those which have had their session set to null by addUninitializedCollection()), calling forceInitialization() which throws a 'collection is not associated with any session' exception.

-- 
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

        



More information about the hibernate-issues mailing list