You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Peter Wieland <pe...@gmx.de> on 2004/08/03 09:26:00 UTC
Multiple instances of one persistent object
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Peter Wieland <pe...@gmx.de>.
Hi Jakob,
thanks for the efforts you are spending on my problems.
We tried ourself some things and in no seems that the problemis gone!
Apparently, we had some concurrent access problems. After making some
methods synchronized, everything seems to work well. I'm not quite sure
whether this was really it. As I said before, the problem was not
reproducable. It just occurred from time to time (rather rarely). I'll tell
you, if it reappears.
> i added a new testcase for proxied references
> ProxyExamples#testReferenceProxies2. this testcase uses one relationship
> only, so it does not exactly match your situation. but the first part
(load real
> obj then proxied obj) shows that a proxied reference is replaced with the
real
> obj if it's already cached.
Yes. This is what happened in 999 out of 1000 times in our app. Just the
remaining one failed. In my eyes, synchronizing problems could be a good
explanation for irregular behaviour like this. So hopefully we really fixed
it.
Thanks again,
Peter
> jakob
> Jakob Braeuchi schrieb:
>> hi peter,
>>
>> does this problem occur only when you navigate over both relationships ?
>> are both items the same ?
>>
>> 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.
>>
>> jakob
>>
>> Peter Wieland schrieb:
>>
>>> 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: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi peter,
i added a new testcase for proxied references
ProxyExamples#testReferenceProxies2. this testcase uses one relationship only,
so it does not exactly match your situation. but the first part (load real obj
then proxied obj) shows that a proxied reference is replaced with the real obj
if it's already cached.
jakob
Jakob Braeuchi schrieb:
> hi peter,
>
> does this problem occur only when you navigate over both relationships ?
> are both items the same ?
>
> 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.
>
> jakob
>
> Peter Wieland schrieb:
>
>> 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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi peter,
here's the link to the identity problem
http://article.gmane.org/gmane.comp.jakarta.ojb.devel/7469
jakob
Peter Wieland schrieb:
> 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: ojb-user-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Peter Wieland <pe...@gmx.de>.
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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi peter,
does this problem occur only when you navigate over both relationships ?
are both items the same ?
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.
jakob
Peter Wieland schrieb:
> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Peter Wieland <pe...@gmx.de>.
> 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
> sclark@support.tat.fws.gov
> (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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Multiple instances of one persistent object
Posted by Steve Clark <sc...@euler.cr.usgs.gov>.
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.
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
sclark@support.tat.fws.gov
(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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org