The cache would only help if the same data, unchanged, is accessed
over and over, so it may not be helpful for this situation, and like
you said especially in a distributed environment (even with
distributed cache clear setup) it could cause problems.
-David
On Nov 1, 2008, at 2:34 PM, Adrian Crum wrote:
I have the view entity working for the outer loop. I still have the
PicklistAndBinAndItem entity-condition because the service is
looking for an empty list being returned (no records found). I don't
know if view entities support something like that.
I haven't enabled the cache on the new view entity because I'm not
sure if it is a wise thing to do. How would concurrency affect the
returned values? In other words, in a very busy environment with
clustered servers working on the same database, are we sure the
returned values are accurate?
-Adrian
--- On Fri, 10/31/08, Adam Heath <[EMAIL PROTECTED]> wrote:
From: Adam Heath <[EMAIL PROTECTED]>
Subject: Re: Performance problem with balanceInventoryItems service
To: [email protected]
Date: Friday, October 31, 2008, 7:31 PM
Adrian Crum wrote:
I have a client who has asked me to look into the
performance problem with the balanceInventoryItems service.
I see from the commit logs that it has been a problem for
others too - David mentions it in the rev 576793 commit log.
I'd like to get this fixed in the trunk. If anyone
has any ideas on ways to improve it, please let me know. I
have some ideas of my own. Maybe together we can get this
fixed.
Hmm, outer query, loop over results, inner getRelated,
second nested
inner loop, and none of this cached.
Yup, perfect candidate for a View.
ps: Hint, a View can contain nested Views. IE, a
member-entity can
point to a view itself.
