Cache in Groovy and Java files

[Jacques Le Roux]

Hi,

It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy and
Java files by their cache overloads (or useCache for findList).
Is there a reason it has not been done yet? I can't see one.

Thanks

Jacques

[Ruth Hoffman-2]

Hi Jacques:
Out of curiosity, I have often wondered about this:
For my own coding, should I use findByPrimaryKey or findOne? Which is
the "better" solution? Regardless of Java, Groovy or other?
TIA
Ruth

On 4/21/11 4:11 AM, Jacques Le Roux wrote:

> Hi,
>
> It would not be a big work effort to replace,and later use only, all
> findByPrimaryKey, findByAnd and also findList in Groovy and Java files
> by their cache overloads (or useCache for findList).
> Is there a reason it has not been done yet? I can't see one.
>
> Thanks
>
> Jacques
>
>
>

[Adrian Crum-3]

http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29

-Adrian

On 4/21/2011 7:52 AM, Ruth Hoffman wrote:

> Hi Jacques:
> Out of curiosity, I have often wondered about this:
> For my own coding, should I use findByPrimaryKey or findOne? Which is
> the "better" solution? Regardless of Java, Groovy or other?
> TIA
> Ruth
>
> On 4/21/11 4:11 AM, Jacques Le Roux wrote:
>> Hi,
>>
>> It would not be a big work effort to replace,and later use only, all
>> findByPrimaryKey, findByAnd and also findList in Groovy and Java
>> files by their cache overloads (or useCache for findList).
>> Is there a reason it has not been done yet? I can't see one.
>>
>> Thanks
>>
>> Jacques
>>
>>
>>

[Ruth Hoffman-2]

Hi Adrian:

I thought I had seen something like that somewhere. Thanks for the
reference. Do you recall if there is someplace that explains the
improvements in findOne over findByPrimaryKey?

Best Regards,
Ruth

On 4/21/11 10:57 AM, Adrian Crum wrote:

> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29 
>
>
> -Adrian
>
> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>> Hi Jacques:
>> Out of curiosity, I have often wondered about this:
>> For my own coding, should I use findByPrimaryKey or findOne? Which is
>> the "better" solution? Regardless of Java, Groovy or other?
>> TIA
>> Ruth
>>
>> On 4/21/11 4:11 AM, Jacques Le Roux wrote:
>>> Hi,
>>>
>>> It would not be a big work effort to replace,and later use only, all
>>> findByPrimaryKey, findByAnd and also findList in Groovy and Java
>>> files by their cache overloads (or useCache for findList).
>>> Is there a reason it has not been done yet? I can't see one.
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>
>

[Adrian Crum-3]

 From what I recall, there is no difference in functionality. The
deprecated methods were merely an effort to simplify the Delegator API.

-Adrian

On 4/21/2011 8:02 AM, Ruth Hoffman wrote:

> Hi Adrian:
>
> I thought I had seen something like that somewhere. Thanks for the
> reference. Do you recall if there is someplace that explains the
> improvements in findOne over findByPrimaryKey?
>
> Best Regards,
> Ruth
>
> On 4/21/11 10:57 AM, Adrian Crum wrote:
>> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29 
>>
>>
>> -Adrian
>>
>> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>>> Hi Jacques:
>>> Out of curiosity, I have often wondered about this:
>>> For my own coding, should I use findByPrimaryKey or findOne? Which
>>> is the "better" solution? Regardless of Java, Groovy or other?
>>> TIA
>>> Ruth
>>>
>>> On 4/21/11 4:11 AM, Jacques Le Roux wrote:
>>>> Hi,
>>>>
>>>> It would not be a big work effort to replace,and later use only,
>>>> all findByPrimaryKey, findByAnd and also findList in Groovy and
>>>> Java files by their cache overloads (or useCache for findList).
>>>> Is there a reason it has not been done yet? I can't see one.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>

[Ruth Hoffman-2]

Hi Adrian:
Thanks much for your quick reply.
Best Regards,
Ruth

On 4/21/11 11:05 AM, Adrian Crum wrote:

> From what I recall, there is no difference in functionality. The
> deprecated methods were merely an effort to simplify the Delegator API.
>
> -Adrian
>
> On 4/21/2011 8:02 AM, Ruth Hoffman wrote:
>> Hi Adrian:
>>
>> I thought I had seen something like that somewhere. Thanks for the
>> reference. Do you recall if there is someplace that explains the
>> improvements in findOne over findByPrimaryKey?
>>
>> Best Regards,
>> Ruth
>>
>> On 4/21/11 10:57 AM, Adrian Crum wrote:
>>> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29 
>>>
>>>
>>> -Adrian
>>>
>>> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>>>> Hi Jacques:
>>>> Out of curiosity, I have often wondered about this:
>>>> For my own coding, should I use findByPrimaryKey or findOne? Which
>>>> is the "better" solution? Regardless of Java, Groovy or other?
>>>> TIA
>>>> Ruth
>>>>
>>>> On 4/21/11 4:11 AM, Jacques Le Roux wrote:
>>>>> Hi,
>>>>>
>>>>> It would not be a big work effort to replace,and later use only,
>>>>> all findByPrimaryKey, findByAnd and also findList in Groovy and
>>>>> Java files by their cache overloads (or useCache for findList).
>>>>> Is there a reason it has not been done yet? I can't see one.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>
>

[Jacques Le Roux]

This is a good reminder, but sorry i'ts out of subject ;o)

Even if I replace findByPrimaryKey by findOne (actually findByPrimaryKey simply calls findOne and I agree we should do, there is
still a lot  to do in current OOTB code: 1169 instances in Java and Groovy files) I will still wonder why not using findOne with
useCache=true everywhere

I see there is a little overhead in code due to calls to ecaRunner.evalRules with EV_CACHE_CHECK/ EV_CACHE_PUT and
getFromPrimaryKeyCache/putInPrimaryKeyCache when actually the entity is not cacheable but it would be largely compensated by real
use of cache when it's cacheable since it's most cases. To optimize, for the cases the entity is not cacheable , we could then later
replace useCache=true by false

Do I miss something?

Jacques

From: "Ruth Hoffman" <[hidden email]>

> Hi Adrian:
> Thanks much for your quick reply.
> Best Regards,
> Ruth
>
> On 4/21/11 11:05 AM, Adrian Crum wrote:
>> From what I recall, there is no difference in functionality. The deprecated methods were merely an effort to simplify the
>> Delegator API.
>>
>> -Adrian
>>
>> On 4/21/2011 8:02 AM, Ruth Hoffman wrote:
>>> Hi Adrian:
>>>
>>> I thought I had seen something like that somewhere. Thanks for the reference. Do you recall if there is someplace that explains
>>> the improvements in findOne over findByPrimaryKey?
>>>
>>> Best Regards,
>>> Ruth
>>>
>>> On 4/21/11 10:57 AM, Adrian Crum wrote:
>>>> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29
>>>>
>>>> -Adrian
>>>>
>>>> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>>>>> Hi Jacques:
>>>>> Out of curiosity, I have often wondered about this:
>>>>> For my own coding, should I use findByPrimaryKey or findOne? Which is the "better" solution? Regardless of Java, Groovy or
>>>>> other?
>>>>> TIA
>>>>> Ruth
>>>>>
>>>>> On 4/21/11 4:11 AM, Jacques Le Roux wrote:
>>>>>> Hi,
>>>>>>
>>>>>> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy
>>>>>> and Java files by their cache overloads (or useCache for findList).
>>>>>> Is there a reason it has not been done yet? I can't see one.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>
>>

[David E. Jones-2]

Jacques,

Are you proposing that by default we cache all find operations?

What are the benefits you are hoping for, and the issues you have considered?

-David


On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote:

> Hi,
>
> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy and Java files by their cache overloads (or useCache for findList).
> Is there a reason it has not been done yet? I can't see one.
>
> Thanks
>
> Jacques
>
>

[Jacques Le Roux]

Hi David,

I have tried to explain my POV a bit more later in the thread.

Jacques

From: "David E Jones" <[hidden email]>

> Jacques,
>
> Are you proposing that by default we cache all find operations?
>
> What are the benefits you are hoping for, and the issues you have considered?
>
> -David
>
>
> On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote:
>
>> Hi,
>>
>> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy and
>> Java files by their cache overloads (or useCache for findList).
>> Is there a reason it has not been done yet? I can't see one.
>>
>> Thanks
>>
>> Jacques
>>
>>
>

[David E. Jones-2]

Do you mean these comments:

======================
I see there is a little overhead in code due to calls to ecaRunner.evalRules with EV_CACHE_CHECK/ EV_CACHE_PUT and
getFromPrimaryKeyCache/putInPrimaryKeyCache when actually the entity is not cacheable but it would be largely compensated by real
use of cache when it's cacheable since it's most cases. To optimize, for the cases the entity is not cacheable , we could then later
replace useCache=true by false
======================

Those comments address the mechanism of doing so, and one possible issue with overhead in a certain configuration, but they don't address the general idea of should we really cache everything by default or not.

So what do you think: should we cache everything by default? What would be the benefit of doing so? What sorts of problems might we cause by doing so?

-David


On Apr 21, 2011, at 10:23 AM, Jacques Le Roux wrote:

> Hi David,
>
> I have tried to explain my POV a bit more later in the thread.
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
>> Jacques,
>>
>> Are you proposing that by default we cache all find operations?
>>
>> What are the benefits you are hoping for, and the issues you have considered?
>>
>> -David
>>
>>
>> On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote:
>>
>>> Hi,
>>>
>>> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy and Java files by their cache overloads (or useCache for findList).
>>> Is there a reason it has not been done yet? I can't see one.
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> Do you mean these comments:
>
> ======================
> I see there is a little overhead in code due to calls to ecaRunner.evalRules with EV_CACHE_CHECK/ EV_CACHE_PUT and
> getFromPrimaryKeyCache/putInPrimaryKeyCache when actually the entity is not cacheable but it would be largely compensated by real
> use of cache when it's cacheable since it's most cases. To optimize, for the cases the entity is not cacheable , we could then
> later
> replace useCache=true by false
> ======================

Yes

> Those comments address the mechanism of doing so, and one possible issue with overhead in a certain configuration, but they don't
> address the general idea of should we really cache everything by default or not.
>
> So what do you think: should we cache everything by default?

Yes I think so. At least there are a lot of places in OOTB code where Entity Cache should be used and is not. Maybe it's history,
not sure...

>What would be the benefit of doing so?

Better performance in most cases. A little overhead after turning to all cached. Could be easily fixed by checking where not cached
Entities are used and replace there with not cached version of find methods

>What sorts of problems might we cause by doing so?

Actually I think that's the question everybody is asking her/himself. This because of insconsistency in current code where some find
should be cached and are not. I can see only the overhead I noted and it could be easily avoided, because there are much more cached
Entities than not cached. I don't see any other problems. Maybe I miss something, because I did not went deep in code, but from a
functional POV I don't think so. So a global change to cached and then local fixes to prevent the overhead is what I'm thinking
about.

Jacques

> -David
>
>
> On Apr 21, 2011, at 10:23 AM, Jacques Le Roux wrote:
>
>> Hi David,
>>
>> I have tried to explain my POV a bit more later in the thread.
>>
>> Jacques
>>
>> From: "David E Jones" <[hidden email]>
>>> Jacques,
>>>
>>> Are you proposing that by default we cache all find operations?
>>>
>>> What are the benefits you are hoping for, and the issues you have considered?
>>>
>>> -David
>>>
>>>
>>> On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote:
>>>
>>>> Hi,
>>>>
>>>> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy
>>>> and Java files by their cache overloads (or useCache for findList).
>>>> Is there a reason it has not been done yet? I can't see one.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>
>>
>

[David E. Jones-2]

If I understand right the issue you are seeing is that some find operations that should be cached are currently not cached. That is most certainly true. Do you have examples of these?

In general with optimization, and use of a cache IS an optimization, it is best to write it using the most clear approach, and then if performance is not acceptable or adequate do profiling and optimization to improve that. Sometimes that optimization might involve caching, and sometimes caching will cause more problems than it will help.

I hate writing this over and over, and I'm sure it's in the wiki somewhere, but the mailing list archives are huge and so is the wiki. In general it is best to use a cache when:

1. high read to write ratio (ie read far more often than it is written)
2. likely to be shared among many users

If those two aren't the case caching might not be the best idea.

Also keep in mind that caches do have a very significant memory footprint. If we cached everything the size of the cache in memory would over time approach the size of the database, and actually because we cache lists of values and not just individual records it could be many many times the size of the database itself.

If you want to try this, even with the demo data (ie a small database), try making the few code changes necessary to cache everything and then put a small load on the server, even just in ecommerce with some browsing and order placement, and watch the memory grow.

Even if you configured the cache to have size limits, with certain user-specific data elements like the Party* entities and the Order* entities you'll have such a low read to write ratio, partly because of #2 above, that the cache will do as much or more harm than good.

If you think this is unreasonable, please do make the case for caching everything. It's certainly an interesting topic to discuss.

-David



On Apr 21, 2011, at 11:23 AM, Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>> Do you mean these comments:
>>
>> ======================
>> I see there is a little overhead in code due to calls to ecaRunner.evalRules with EV_CACHE_CHECK/ EV_CACHE_PUT and
>> getFromPrimaryKeyCache/putInPrimaryKeyCache when actually the entity is not cacheable but it would be largely compensated by real
>> use of cache when it's cacheable since it's most cases. To optimize, for the cases the entity is not cacheable , we could then later
>> replace useCache=true by false
>> ======================
>
> Yes
>
>> Those comments address the mechanism of doing so, and one possible issue with overhead in a certain configuration, but they don't address the general idea of should we really cache everything by default or not.
>>
>> So what do you think: should we cache everything by default?
>
> Yes I think so. At least there are a lot of places in OOTB code where Entity Cache should be used and is not. Maybe it's history, not sure...
>
>> What would be the benefit of doing so?
>
> Better performance in most cases. A little overhead after turning to all cached. Could be easily fixed by checking where not cached Entities are used and replace there with not cached version of find methods
>
>> What sorts of problems might we cause by doing so?
>
> Actually I think that's the question everybody is asking her/himself. This because of insconsistency in current code where some find should be cached and are not. I can see only the overhead I noted and it could be easily avoided, because there are much more cached Entities than not cached. I don't see any other problems. Maybe I miss something, because I did not went deep in code, but from a functional POV I don't think so. So a global change to cached and then local fixes to prevent the overhead is what I'm thinking about.
>
> Jacques
>
>
>> -David
>>
>>
>> On Apr 21, 2011, at 10:23 AM, Jacques Le Roux wrote:
>>
>>> Hi David,
>>>
>>> I have tried to explain my POV a bit more later in the thread.
>>>
>>> Jacques
>>>
>>> From: "David E Jones" <[hidden email]>
>>>> Jacques,
>>>>
>>>> Are you proposing that by default we cache all find operations?
>>>>
>>>> What are the benefits you are hoping for, and the issues you have considered?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy and Java files by their cache overloads (or useCache for findList).
>>>>> Is there a reason it has not been done yet? I can't see one.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>
>>>
>
>

[Jacques Le Roux]

David,

Thanks for your feedback and sorry, indeed your answer makes totally sense, I should have had a look before in the MLs.

The cases which are interesting me are when they should be cached and are not OOTB. I finally agree with you that blindly
generalizing
could be worse than letting as is (premature optimization). I notably missed the point about sharing among users. I went that way
because I'm working on a site where there will be very few products with plenty of memory on web app servers but much less (still
fairly decent) on DB servers. I definitively need to have a closer look...

I have though already some examples which could be interesting to cache, even OOTB, notably in Groovy scripts. Of course not with
thousands of products, though, even then, OFBiz users could go the other way: see where there is too much cache memory usage and
adjust locally. I could have given more details but it would have been too long and I think Entities names are enough at this stage.
This is mostly from Groovy scripts in ecommerce and ordermgnr (not exhaustive) , those entities are cacheable.

Product
ProductFeature
ProductCategoryMember
ProductPromo
ProductFeatureAndAppl
ProductStoreSurveyAppl

MimeType

Enumeration

ContactList

ContactMechPurposeType
PartyContentType
ShipmentMethodType
ReturnType
ReturnReason
ReturnItemTypeMap

Jacques

From: "David E Jones" <[hidden email]>

> If I understand right the issue you are seeing is that some find operations that should be cached are currently not cached. That
> is most certainly true. Do you have examples of these?
>
> In general with optimization, and use of a cache IS an optimization, it is best to write it using the most clear approach, and
> then if performance is not acceptable or adequate do profiling and optimization to improve that. Sometimes that optimization might
> involve caching, and sometimes caching will cause more problems than it will help.
>
> I hate writing this over and over, and I'm sure it's in the wiki somewhere, but the mailing list archives are huge and so is the
> wiki. In general it is best to use a cache when:
>
> 1. high read to write ratio (ie read far more often than it is written)
> 2. likely to be shared among many users
>
> If those two aren't the case caching might not be the best idea.
>
> Also keep in mind that caches do have a very significant memory footprint. If we cached everything the size of the cache in memory
> would over time approach the size of the database, and actually because we cache lists of values and not just individual records
> it could be many many times the size of the database itself.
>
> If you want to try this, even with the demo data (ie a small database), try making the few code changes necessary to cache
> everything and then put a small load on the server, even just in ecommerce with some browsing and order placement, and watch the
> memory grow.
>
> Even if you configured the cache to have size limits, with certain user-specific data elements like the Party* entities and the
> Order* entities you'll have such a low read to write ratio, partly because of #2 above, that the cache will do as much or more
> harm than good.
>
> If you think this is unreasonable, please do make the case for caching everything. It's certainly an interesting topic to discuss.
>
> -David
>
>
>
> On Apr 21, 2011, at 11:23 AM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> Do you mean these comments:
>>>
>>> ======================
>>> I see there is a little overhead in code due to calls to ecaRunner.evalRules with EV_CACHE_CHECK/ EV_CACHE_PUT and
>>> getFromPrimaryKeyCache/putInPrimaryKeyCache when actually the entity is not cacheable but it would be largely compensated by
>>> real
>>> use of cache when it's cacheable since it's most cases. To optimize, for the cases the entity is not cacheable , we could then
>>> later
>>> replace useCache=true by false
>>> ======================
>>
>> Yes
>>
>>> Those comments address the mechanism of doing so, and one possible issue with overhead in a certain configuration, but they
>>> don't address the general idea of should we really cache everything by default or not.
>>>
>>> So what do you think: should we cache everything by default?
>>
>> Yes I think so. At least there are a lot of places in OOTB code where Entity Cache should be used and is not. Maybe it's history,
>> not sure...
>>
>>> What would be the benefit of doing so?
>>
>> Better performance in most cases. A little overhead after turning to all cached. Could be easily fixed by checking where not
>> cached Entities are used and replace there with not cached version of find methods
>>
>>> What sorts of problems might we cause by doing so?
>>
>> Actually I think that's the question everybody is asking her/himself. This because of insconsistency in current code where some
>> find should be cached and are not. I can see only the overhead I noted and it could be easily avoided, because there are much
>> more cached Entities than not cached. I don't see any other problems. Maybe I miss something, because I did not went deep in
>> code, but from a functional POV I don't think so. So a global change to cached and then local fixes to prevent the overhead is
>> what I'm thinking about.
>>
>> Jacques
>>
>>
>>> -David
>>>
>>>
>>> On Apr 21, 2011, at 10:23 AM, Jacques Le Roux wrote:
>>>
>>>> Hi David,
>>>>
>>>> I have tried to explain my POV a bit more later in the thread.
>>>>
>>>> Jacques
>>>>
>>>> From: "David E Jones" <[hidden email]>
>>>>> Jacques,
>>>>>
>>>>> Are you proposing that by default we cache all find operations?
>>>>>
>>>>> What are the benefits you are hoping for, and the issues you have considered?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It would not be a big work effort to replace,and later use only, all findByPrimaryKey, findByAnd and also findList in Groovy
>>>>>> and Java files by their cache overloads (or useCache for findList).
>>>>>> Is there a reason it has not been done yet? I can't see one.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>