> Probably one of the objects is a proxy and the other is the real
> object. It's dangerous to rely on instance equality when proxies
> might be present, because it's possible to have several proxies which
> refer to the same object.
I can definitely exclude this possibility. Our getters internally look like
public Item getItem() {
Item retValue = null;
if (this.item instanceof Proxy) {
retValue = (Item)((IndirectionHandler)Proxy.getInvocationHandler(this.it
em)).getRealSubject()
} else {
retValue = this.item;
}
return retValue;
}
Peter
> --
> Steve Clark
> Technology Applications Team
> Natural Resources Research Center/USGS
> [EMAIL PROTECTED]
> (970)226-9291
> Peter> Hi, I stepped over the following problem yesterday. Took us
> Peter> half the day to get some understanding of what's going on,
> Peter> but we could not figure out how to fix it:
> Peter> We have three objects: Order <-> Item <-> Aggregate
> Peter> connected with to (bidirectional) 1-to-1 associations. All
> Peter> of the associations are configured to be proxies lazily
> Peter> loaded on first accessing them. I was starting from an
> Peter> Order and navigated to the Aggregate and backwards to the
> Peter> Order what resulted in two different instances of the same
> Peter> order object (same persistent identity, different Java
> Peter> object identity):
> Peter> Order order1 = getAnOrderFromSomeWhere();
> Peter> Aggregate aggr = order1.getItem().getAggregate();
> Peter> Order order2 = aggr.getItem().getOrder();
> Peter> // result
> Peter> order2.equals(order1) // true
> Peter> order2 != order1 // true
> Peter> Normally this should never happen, as we use one single
> Peter> global ObjectCache (at least this is what I thought how it
> Peter> should be). We use the default ObjectCacheDefaultImpl with
> Peter> no timeout and autoSync set to false. Objects are never
> Peter> removed manually from the cache by our application.
> Peter> I see three possibilities (and have one suspect):
> Peter> 1) Objects get removed from the cache by the garbage
> Peter> collector, when they are only softly reachable. But as I
> Peter> have normal references on the first Order object in my app,
> Peter> this should not happen.
> Peter> 2) Some Identity confusion occurrs. I described a problem
> Peter> with different OJB Identities for the same Object
> Peter> implementing more than one Interface and thus having more
> Peter> than one TopLevelClass. But in this particular case, the
> Peter> TopLevelClass of all of my objects is unique and I do not
> Peter> see any other reason, why OJB Identities should be mixed
> Peter> up.
> Peter> 3) Maybe it has to do with the InternalCache used as iterim
> Peter> cache by OJB before pushing objects to the real cache. If
> Peter> for some reasons, two PersistenceBrokers load the same
> Peter> Object at a time, there would be two instances of this
> Peter> object in the two internal caches. Only after these objects
> Peter> are pushed to the global cache, other PersistenceBroker
> Peter> instances would be aware of these objects. As you may
> Peter> guess, this is my suspect.
> Peter> I do not know exactly when the different objects get
> Peter> loaded, as the problem is very hard to reproduce. It just
> Peter> occurrs from time to time after working for a while with
> Peter> our application.
> Peter> Has anybody an idea what really happens and how to
> Peter> fix/avoid/work around it?
> Peter> Thanks for any help,
> Peter> Peter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]