I have noticed this is a common problem and the solution is not to share the entities between different collections.

I have somewhat different situation I think, I have a transaction that include the creation of several objects, in the same transaction using the PROPAGATION_REQUIRED type i try to query for certain elements that were not loaded before and get the error, when querying using PROPAGATION_NOT_SUPPORTED, it works OK.
I was using spring declarative transaction management and set all my get* to use the PROPAGATION_REQUIRED as some entities have lazy loaded associations. Before I change all my transactions on get that does not have lazy loaded associations I wanted to ask if the problem is familiar to anybody. are the entities sharing some basic elements? the entities I am loading have no association whatsoever with anything and are the simplest beans possible (id and String). the only difference I can think of between the two transaction types is the cache that differs, is the cache limtied in size?

thanks,
tomer

Hibernate version:3.0.5

I have the problem in many mappings, ehre is a sample:
Mapping documents:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="a">
<class table="METRO_CITIES" name="MetroCities">
<cache usage="read-write"/>
<id name="id" type="int" column="METRO_CITIES_ID"></id>
<property name="metroCode" column="METRO_CODE" />
<property name="city" column="CITY" />
</class>
</hibernate-mapping>

Code between sessionFactory.openSession() and session.close():
there aer many calls to get and save and creating new associations


Full stack trace of any exception that occurs:
org.hibernate.HibernateException: Found shared references to a collection
at org.hibernate.engine.Collections.processReachableCollection(Collectio
ns.java:138)
at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.j
ava:37)
at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.
java:101)
at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.
java:61)
at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(A
bstractVisitor.java:55)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity
(DefaultFlushEntityEventListener.java:159)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(A
bstractFlushingEventListener.java:187)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverything
ToExecutions(AbstractFlushingEventListener.java:73)
at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(Def
aultAutoFlushEventListener.java:39)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:7
29)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1307)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:298)
at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:431)

Name and version of the database you are using:Oracle 10.0.2

shared references to a collections means that somewhere you do something functionally equivalent to:


e1 and e2 now share a reference to the *same collection instance*. That is not allowed.

Thanks for your answer,

The entity that throws this exception is a simple one that is not associated to any other entity in any way, the exception is being thrown on the first attemp to query for collections of this entity and it is also being solved by executing the specific query inside PROPAGATION_NOT_SUPPORTED transaction.

Also, all other places using this queries are working fine and in only one transaction I find the problem.

Looking into this specific transaction I see that I load, modify and store several other entities but has nothing to do with the entities that throw this exception, on the first attemp to load a collection of that entity, it throws this exception, changing the transaction type for this action caused the application to throws the exception on another query for an entity of different type.

I double checked for the reference you sent in my code and couldnt see any such behavior for the specific entity (as the exception is being thrown in the Query.list method on the first attemp to load such entity which is simple and is not referred by or referring to any other entity.

does the processReachableCollection() check all collections in the transaction and so may refer to a different entity and be thrown in the specific Query.list by chance only?

Thanks,
tomer

Regarding the shared reference example, I have found I am iterating over a collection of String values of one entity and adding them to another entity a little before the place the exception is being thrown.

Although the collection itself is a different object and the elements are strings, can that cause the exception?



thanks

aCampaign.addGeoTargeting( new String( (String)it.next() ) );

A String is just another Object. With that said the instance number (ala java.lang.String@1234abcd) is identical. So if you meant to save another instance you have to make one. Object uniqueness is not be confused with object equality. There is plenty of Hibernate documentation I've read that explain equality situation, but not so much I've come across about uniqueness.

Thank you for your reply dlmiles,

I am ashamed to admit I found at the end the exact problem specified by Steve of the form:

Entity e1 = ( Entity ) s.load( Entity.class, "1" );
Entity e2 = ( Entity ) s.load( Entity.class, "2" );
e1.setCollection( e2.getCollection() );

I just wanted to clarify on this issue.

the situtation in our code was in relation to many-to-many association and the only difference we did is not reusing the collection object, is that because the collection was lazy initialized?

Also about the reusage of Objects in the one-to-many association as specified earlier in this thread, It is clear to me why not to resuse such entities but other object types as Dates and Strings, the DB treats them as primitive types and they dont have any real identity, does it still pose a problem?

Thanks,
tomer