[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2862?page=c...
]
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira