hi john,

have you tried disabling the collection-desriptor tweaking in RelationshipPrefetcherImpl#prepareRelationshipSettings() ?

public void prepareRelationshipSettings()
{
setCascadeRetrieve(getObjectReferenceDescriptor().getCascadeRetrieve());
getObjectReferenceDescriptor().setCascadeRetrieve(false);  // comment it
}


jakob


John wrote:
I sensed that, but I'm not sure the penalty for loading an object twice is is bad as the penalty I was getting. A lot of places in our code assume the object reference is loaded on a required relationship. One thread was prefetching and turned off auto-retrieve, then another came in and thought that was the right value and set it back to that. So from then on none of the objects had the relationship loaded and I got NullPointerException everywhere.
I suppose that multiple loads could be more of an issue with the global cache, but with cache-per-broker I'm not sure if that's an issue. At least to me double-load isn't as big a deal as the NPE's. I had to discontinue using prefetch in the couple of places I was using it. (Not sure that's the worst thing anyway, since I don't know that it helped a whole lot.)


John


===== Original Message From Jakob Braeuchi <[EMAIL PROTECTED]> =====
hi john,


John wrote:



Has there been any solution to this issue (OJB188)? This bit me in the

butt,


but of course it took quite a bit of digging and debugging to realize this

is


what was happening. Why exactly is the value changed while prefetching?


auto-retrieve is disabled during prefetching of a relationship to avoid loading the same obj multiple times.

jakob


I have a patched version of OJB that was based on HEAD from the middle of
August, so I haven't been able to update for a while (don't want to

repatch).


It seems that there have been some changes to OJB since then with regards

to


(proxy) prefetching, autoretrieve, etc, especially in how those are

configured


in the repository. Are these summarized anywhere?

John Marshall
Connectria


============================================= Date: Fri, 11 Jul 2003 18:19:33 +0200 From: Jakob Braeuchi <[EMAIL PROTECTED]> Subject: Potential problem with prefetch-relationships ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed


hi theo,


during prefetch auto-retrieve is disabled. when an other thread uses the
relationship-desriptor it will find auto-retrive off.
this is a known problem but i do not have a solution for it :(


jakob


Theo Niemeijer wrote:



Hi all,
I seemed to have stumbled on a potential problem with
the "prefetch relationship" option in PB query.

After using prefetchRelationship for retrieval of big list of results,
and at the same time performing other queries,
I seemed to have lost the "auto-retrieve" attribute on
the collection descriptor.

The result was that subsequent queries did not
retrieve that collection anymore, probably because the
"auto-retrieve" was disabled.

The problem is quite hard to reproduce, but my guess is
that different threads modified the repository descriptor
in the wrong sequence, by means of the setCascadeRetrieve
method used in prepareRelationshipSettings.

I might be wrong, because I simply do not oversee all aspects
of OJB. But am I right to view this as a potential problem
in "concurrency situations" like websites ?
I do not feel too comfortable that OJB makes these "temporary"
changes to the repository model.

Cheers,
        Theo Niemeijer



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




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to