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

Reply via email to