Hi Jakob well, it is not really that important anymore, as it seems to work now, but nevertheless I woul very much like to get a little deeper understanding. Thus, this post.
> does this problem occur only when you navigate over both relationships ? > are both items the same ? No. Sorry. I was not very clear in this point. I can't tell you exactly what happened (my other computer crashed today, so logs are gone :-(), but I thin what happened was order1.getItem() != order1.getItem().getAggregate().getItem() and (!) order1 != order1.getItem().getAggregate().getItem().getOrder() But I do not think that the navigation over two assocs is relevant here. > i see a fourth possibilty: > the identity of order1 (not proxied) is not equal to the identity of > item.getOrder() because of different primitives used to build the pk. > there have been post about identities created based on the definition in > the > repository and other based on the jdbc-types. Sorry, I do not understand this. Looked for the posts you are talking of, but there are tons of posts talking about Identity and Identity problems. Any hints when those were posted to the list? Peter >> Hi, >> >> I stepped over the following problem yesterday. Took us half the day to >> get >> some understanding of what's going on, but we could not figure out how to >> fix it: >> >> We have three objects: Order <-> Item <-> Aggregate connected with to >> (bidirectional) 1-to-1 associations. All of the associations are >> configured >> to be proxies lazily loaded on first accessing them. I was starting from >> an >> Order and navigated to the Aggregate and backwards to the Order what >> resulted in two different instances of the same order object (same >> persistent identity, different Java object identity): >> >> Order order1 = getAnOrderFromSomeWhere(); >> Aggregate aggr = order1.getItem().getAggregate(); >> Order order2 = aggr.getItem().getOrder(); >> >> // result >> order2.equals(order1) // true >> order2 != order1 // true >> >> >> Normally this should never happen, as we use one single global >> ObjectCache >> (at least this is what I thought how it should be). We use the default >> ObjectCacheDefaultImpl with no timeout and autoSync set to false. Objects >> are never removed manually from the cache by our application. >> >> I see three possibilities (and have one suspect): >> >> 1) Objects get removed from the cache by the garbage collector, when they >> are only softly reachable. But as I have normal references on the first >> Order object in my app, this should not happen. >> >> 2) Some Identity confusion occurrs. I described a problem with different >> OJB >> Identities for the same Object implementing more than one Interface and >> thus >> having more than one TopLevelClass. But in this particular case, the >> TopLevelClass of all of my objects is unique and I do not see any other >> reason, why OJB Identities should be mixed up. >> >> 3) Maybe it has to do with the InternalCache used as iterim cache by OJB >> before pushing objects to the real cache. If for some reasons, two >> PersistenceBrokers load the same Object at a time, there would be two >> instances of this object in the two internal caches. Only after these >> objects are pushed to the global cache, other PersistenceBroker instances >> would be aware of these objects. As you may guess, this is my suspect. >> >> I do not know exactly when the different objects get loaded, as the >> problem >> is very hard to reproduce. It just occurrs from time to time after >> working >> for a while with our application. >> >> Has anybody an idea what really happens and how to fix/avoid/work around >> it? >> >> Thanks for any help, >> >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
