Thanks for the feedback. We're still learning more and more about what OJB
offers. 

eg. I see in the "how to" you referred to that with auto-retrieve set to
false you can still make use of broker.retrieveReferences() methods which I
hadn't come across before. Will have to go back and make use of that in a
few instances for lazy loading!

Cheers
Stuart

-----Original Message-----
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Monday, 16 February 2004 10:16 AM
To: OJB Users List
Subject: Re: RC5 and cyclic references PROBLEM


Hi Stuart,

Stuart Heriot wrote:

> Hi Armin, 
> 
> Loop occurs on lookup. Yes we do override the equals methods. Is this
> significant?

Now, after reading your post I think no.

> 
> We use the empty object cache implementation...
> ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
> 

Now it's clear, sorry but I'm responsible for your problem. I made some
changes in ObjectCacheEmptyImpl and forget to put a note in the release 
notes. ObjectCacheEmptyImpl does solve cicular references by using 
internal Map to cache objects while tx-/PB instance lifetime, but in FAQ 
we say it was a real no-op implementation of ObjectCache interface. Some 
user don't expect such a behaviour from an "EmptyCache" implementation.
See
<http://db.apache.org/ojb/faq.html#How to work with the
ObjectCacheEmptyImpl>

The problem with the previous version of ObjectCacheEmptyImpl was, if 
you only read objects (without a transaction) and do not close the PB 
instance after use (reuse the instance by your own, instead let OJB do 
this automatic for you), the internal map will not be cleared after use. 
This was the price to pay for resolving cicular references.

Alternative you can use ObjectCachePerBrokerImpl, this implementation 
clear cache on PB.close call or implement previous version of 
ObjectCacheEmptyImpl again.

Sorry for the hassle.

regards,
Armin

> My comments regarding the effect of auto-retrieve="false" were not
correct.
> When I isolated our problem classes I eventually found the cyclic
reference
> (there are a number of nested collections and reference descriptors
> involved). Setting auto-retrieve to false on the problem reference
> descriptor did fix the problem. However this is still different behaviour
> between rc4 and rc5. 
> 
> Thanks
> Stuart
> 
> -----Original Message-----
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: Friday, 13 February 2004 8:12 PM
> To: OJB Users List
> Subject: Re: RC5 and cyclic references PROBLEM
> 
> 
> Hi Stuart,
> 
> Stuart Heriot wrote:
> 
>>G'day, 
>>
>>I've been testing rc5 and am seeing some unexpected behaviour with regard
>>cyclic references (eg. ClassA contains a collection of ClassB ojbects.
>>ClassB contains a reference to a ClassA object. 
>>
>>We have been running with rc4 ok but when we run with rc5, same code same
>>repository, it does not resolve the cyclic reference and gets caught in a
>>loop when you retrieve ClassA, which retrieves collection of ClassB each
> 
> of
> 
>>which retrieve an instance of ClassA which then retrieves collection of
>>ClassB each of which.... and on it goes!
>>
>>This occurs even when we set auto-retrieve="false" on all collection and
>>reference descriptors.
> 
> 
> hmm, sounds strange.
> When does the infinite loop occur - lookup, store delete?
> Do you override equals method in your persistance capable objects?
> 
> 
>>Has something been broken in rc5 or is there some change required to the
>>repository file for this to work correctly?
> 
> 
> Which ObjectCache implementation do you use? In ObjectCacheDefaultImpl 
> was a bug in handling cached objects (use of SoftReferences), so under 
> heavy load current cached objects may gc.
> 
> Try latest from CVS HEAD and see what's going on.
> 
> regards,
> Armin
> 
> 
>>Thanks in advance
>>Stuart Heriot
>>
> 
> 
> ---------------------------------------------------------------------
> 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