Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

On Jul 27, 2011, at 6:49 PM, Dzmitry Kazimirchyk (JIRA) wrote:

> 
> There may be some difficulties with this because EHCache unlike OSCache doesn't have support for cache groups which Cayenne actively uses. As I've searched this is a major problem for all users migrating from OSCache to EHCache and EHCache even has Jira for it: https://jira.terracotta.org/jira/browse/EHC-240 .

Oops. Now I am starting to remember why we picked OSCache against EHCache for Cayenne in the first place... Yeah, seems like OSCache is unique in respect to "cache groups" feature. 

After a quick repeat look at EhCache after many years, it is definitely pretty advanced (I am surprised it doesn't support groups considering everything else it supports) and I see a bunch of things that I like. E.g. multiple caches per CacheManager allows to split cache into regions which seems suitable to serve for unified cache approach between object and query caches (something that's been on the list for some time). And IIRC this is how Hibernate does it. 

Besides with some tweaking it allows to emulate a few OSCache behaviors I am used to. E.g. cluster cache replication is done by copy by default, but it can be configured to be done via a much lighter invalidation mechanism (trading consistency for performance - something I am willing to do in the apps I am mostly dealing with).

> The question is should we wait for EHCache to implement cache groups or write our custom solution for this? (or maybe something else)

Good question... From the Jira history, this issue has been shifted around for 2 years by Terracotta, so it is hard to tell when it becomes standard. 

I suspect a custom implementation will be either complex, requiring a rewrite of big parts of EhCache, or inefficient (such as our own MapQueryCache that scans the entire cache to remove all items belonging to a group. I guess we can inspect the user patches and make a decision on that. 

I think we can start with an implementation that quietly ignores groups and uses a single cache (and hence a single expiration policy) for all query entries. It is rather crippled, as it would preclude targeted invalidation, but it will be a start. And then who knows, maybe EHC-240 is committed.

Andrus

P.S. Also after joining Terracotta, EhCache became sneaky spyware: http://adammonsen.com/post/512 Big surprise :-/

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

On Jul 27, 2011, at 11:16 PM, Andrus Adamchik wrote:

> I think we can start with an implementation that quietly ignores groups and uses a single cache (and hence a single expiration policy) for all query entries. It is rather crippled, as it would preclude targeted invalidation, but it will be a start. And then who knows, maybe EHC-240 is committed.

So here is an attempt of cache group design over EHCache... 

First, a few assumptions:

1. if a query has multiple cache groups, we ignore all but the first one. This is quite reasonable IMO. It will suffice for most scenarios.

2. We store keys for each cache group in a separate EHCache instance within the same CacheManager. 

3. For entries with no cache groups, we allocate a separate EHCache instance.

I think this will allow us to implement all methods of QueryCache interface. However we may end up with duplicate cache entries if the same query was run with different cache groups, which may potentially increase memory use and introduce a new type of cache consistency problems. So it is not as flexible as OSCache, but is much better than no cache group support at all. As long as users are aware of it, we should be fine.
 
Andrus

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

On Jul 28, 2011, at 9:58 AM, Christian Grobmeier wrote:

> I mean - transparent migration, transparent API, and just in case
> there is something going on I get a warning. Sounds like a good deal
> to me.

Yeah, I am leaning to #3 with a warning which has no performance tradeoffs and still lets the user know that he may be doing something wrong.

> Spoken with my user hat on, I never used EHCache or OSCache directly

To me there's an important scenario when XyzCache is used by the application outside Cayenne for its own caching needs and then Cayenne integrates into the same instance of cache provider to do its own thing. This way when setting cache group expiration policy, or invalidating a cache group, I can control both Cayenne and application cache entries in one place. Although even OSCache provider didn't handle this scenario out of the box (it would create its own cache instead of integrating with an application one, so I'd write my own provider). 

I guess with EHCache we can think how to handle this scenario. After all now we have DI that would allow users to pass their own CacheManager to the provider.

Andrus

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Christian Grobmeier <gr...@gmail.com>]

from what I learned now, a warning would be good.

I mean - transparent migration, transparent API, and just in case
there is something going on I get a warning. Sounds like a good deal
to me.

Spoken with my user hat on, I never used EHCache or OSCache directly



On Thu, Jul 28, 2011 at 8:53 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> But yeah, API-wise it should be transparent to the users and in case we go with 1 (or warn instead of throw), even migration from OSCache will be transparent.
>
>
> On Jul 28, 2011, at 9:51 AM, Andrus Adamchik wrote:
>
>> End users will need to understand (a) when planning their cache group use.
>>
>> (b) is explicitly allowed by Cayenne SelectQuery (and other queries) API. Also this can happen implicitly when 2 queries with different cache groups resolve to the same key. We have some options here:
>>
>> 1. Quietly ignore the possibility of multiple cache groups. In explicit case use the first group, don't try to analyze the implicit case.
>> 2. Throw (or warn via the logs) on multiple cache groups per key. In explicit case it will be easy to detect, in implicit case it will require a scan of N caches (where N is the number of cache groups in the system).
>> 3. Throw (or warn via the logs) on multiple explicit cache groups per key. Ignore implicit ones.
>>
>> Andrus
>>
>>
>> On Jul 28, 2011, at 9:37 AM, Christian Grobmeier wrote:
>>> Thanks for your explaination
>>>
>>>> (a) require more discipline from the users in assigning cache groups and
>>>> (b) disallow multiple cache groups per key (be it for the same query instance or for different, but equivalent query instances).
>>>
>>> But surely this is something the enduser aka Cayenne-user will not
>>> have to deal with it right?
>>> In my imagination I choose "EHCache" from the modeler and Cayenne is
>>> doing everything for me.
>>>
>>>
>>>>
>>>>
>>>> On Jul 28, 2011, at 12:01 AM, Andrus Adamchik wrote:
>>>>> On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote:
>>>>>
>>>>>> What is the difference to Cache-Groups then?
>>>>>
>>>>> (Also see my other email on this)
>>>>>
>>>>> The difference is subtle, but may be essential in some scenarios. OSCache cache groups are "tags" that can be applied to any combinations of cache keys (including multiple groups per key). E.g. on a certain event you may invalidate group1, and on some other event - group2, and these two groups may span over overlapping (but not equivalent) sets of keys.
>>>>>
>>>>> Using EhCache instances to emulate cache groups implies a hierarchy. All keys belong to either zero or one cache group. Now the user must ensure that 2 queries with the same cache key, but created in different places of the code are using the same group.
>>>>>
>>>>> This is not the end of the world of course, and I must admit that most often than not queries are actually organized this way already.
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>>
>>
>>
>
>



-- 
http://www.grobmeier.de

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

But yeah, API-wise it should be transparent to the users and in case we go with 1 (or warn instead of throw), even migration from OSCache will be transparent.


On Jul 28, 2011, at 9:51 AM, Andrus Adamchik wrote:

> End users will need to understand (a) when planning their cache group use. 
> 
> (b) is explicitly allowed by Cayenne SelectQuery (and other queries) API. Also this can happen implicitly when 2 queries with different cache groups resolve to the same key. We have some options here:
> 
> 1. Quietly ignore the possibility of multiple cache groups. In explicit case use the first group, don't try to analyze the implicit case.
> 2. Throw (or warn via the logs) on multiple cache groups per key. In explicit case it will be easy to detect, in implicit case it will require a scan of N caches (where N is the number of cache groups in the system).
> 3. Throw (or warn via the logs) on multiple explicit cache groups per key. Ignore implicit ones.
> 
> Andrus
> 
> 
> On Jul 28, 2011, at 9:37 AM, Christian Grobmeier wrote:
>> Thanks for your explaination
>> 
>>> (a) require more discipline from the users in assigning cache groups and
>>> (b) disallow multiple cache groups per key (be it for the same query instance or for different, but equivalent query instances).
>> 
>> But surely this is something the enduser aka Cayenne-user will not
>> have to deal with it right?
>> In my imagination I choose "EHCache" from the modeler and Cayenne is
>> doing everything for me.
>> 
>> 
>>> 
>>> 
>>> On Jul 28, 2011, at 12:01 AM, Andrus Adamchik wrote:
>>>> On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote:
>>>> 
>>>>> What is the difference to Cache-Groups then?
>>>> 
>>>> (Also see my other email on this)
>>>> 
>>>> The difference is subtle, but may be essential in some scenarios. OSCache cache groups are "tags" that can be applied to any combinations of cache keys (including multiple groups per key). E.g. on a certain event you may invalidate group1, and on some other event - group2, and these two groups may span over overlapping (but not equivalent) sets of keys.
>>>> 
>>>> Using EhCache instances to emulate cache groups implies a hierarchy. All keys belong to either zero or one cache group. Now the user must ensure that 2 queries with the same cache key, but created in different places of the code are using the same group.
>>>> 
>>>> This is not the end of the world of course, and I must admit that most often than not queries are actually organized this way already.
>>>> 
>>>> Andrus
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> http://www.grobmeier.de
>> 
> 
> 

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

End users will need to understand (a) when planning their cache group use. 

(b) is explicitly allowed by Cayenne SelectQuery (and other queries) API. Also this can happen implicitly when 2 queries with different cache groups resolve to the same key. We have some options here:

1. Quietly ignore the possibility of multiple cache groups. In explicit case use the first group, don't try to analyze the implicit case.
2. Throw (or warn via the logs) on multiple cache groups per key. In explicit case it will be easy to detect, in implicit case it will require a scan of N caches (where N is the number of cache groups in the system).
3. Throw (or warn via the logs) on multiple explicit cache groups per key. Ignore implicit ones.

Andrus


On Jul 28, 2011, at 9:37 AM, Christian Grobmeier wrote:
> Thanks for your explaination
> 
>> (a) require more discipline from the users in assigning cache groups and
>> (b) disallow multiple cache groups per key (be it for the same query instance or for different, but equivalent query instances).
> 
> But surely this is something the enduser aka Cayenne-user will not
> have to deal with it right?
> In my imagination I choose "EHCache" from the modeler and Cayenne is
> doing everything for me.
> 
> 
>> 
>> 
>> On Jul 28, 2011, at 12:01 AM, Andrus Adamchik wrote:
>>> On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote:
>>> 
>>>> What is the difference to Cache-Groups then?
>>> 
>>> (Also see my other email on this)
>>> 
>>> The difference is subtle, but may be essential in some scenarios. OSCache cache groups are "tags" that can be applied to any combinations of cache keys (including multiple groups per key). E.g. on a certain event you may invalidate group1, and on some other event - group2, and these two groups may span over overlapping (but not equivalent) sets of keys.
>>> 
>>> Using EhCache instances to emulate cache groups implies a hierarchy. All keys belong to either zero or one cache group. Now the user must ensure that 2 queries with the same cache key, but created in different places of the code are using the same group.
>>> 
>>> This is not the end of the world of course, and I must admit that most often than not queries are actually organized this way already.
>>> 
>>> Andrus
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> -- 
> http://www.grobmeier.de
> 

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Christian Grobmeier <gr...@gmail.com>]

Thanks for your explaination

> (a) require more discipline from the users in assigning cache groups and
> (b) disallow multiple cache groups per key (be it for the same query instance or for different, but equivalent query instances).

But surely this is something the enduser aka Cayenne-user will not
have to deal with it right?
In my imagination I choose "EHCache" from the modeler and Cayenne is
doing everything for me.


>
>
> On Jul 28, 2011, at 12:01 AM, Andrus Adamchik wrote:
>> On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote:
>>
>>> What is the difference to Cache-Groups then?
>>
>> (Also see my other email on this)
>>
>> The difference is subtle, but may be essential in some scenarios. OSCache cache groups are "tags" that can be applied to any combinations of cache keys (including multiple groups per key). E.g. on a certain event you may invalidate group1, and on some other event - group2, and these two groups may span over overlapping (but not equivalent) sets of keys.
>>
>> Using EhCache instances to emulate cache groups implies a hierarchy. All keys belong to either zero or one cache group. Now the user must ensure that 2 queries with the same cache key, but created in different places of the code are using the same group.
>>
>> This is not the end of the world of course, and I must admit that most often than not queries are actually organized this way already.
>>
>> Andrus
>>
>>
>>
>>
>
>



-- 
http://www.grobmeier.de

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

More concisely, EhCache implementation will:

(a) require more discipline from the users in assigning cache groups and 
(b) disallow multiple cache groups per key (be it for the same query instance or for different, but equivalent query instances).


On Jul 28, 2011, at 12:01 AM, Andrus Adamchik wrote:
> On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote:
> 
>> What is the difference to Cache-Groups then?
> 
> (Also see my other email on this) 
> 
> The difference is subtle, but may be essential in some scenarios. OSCache cache groups are "tags" that can be applied to any combinations of cache keys (including multiple groups per key). E.g. on a certain event you may invalidate group1, and on some other event - group2, and these two groups may span over overlapping (but not equivalent) sets of keys. 
> 
> Using EhCache instances to emulate cache groups implies a hierarchy. All keys belong to either zero or one cache group. Now the user must ensure that 2 queries with the same cache key, but created in different places of the code are using the same group. 
> 
> This is not the end of the world of course, and I must admit that most often than not queries are actually organized this way already. 
> 
> Andrus
> 
> 
> 
> 

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Andrus Adamchik <an...@objectstyle.org>]

On Jul 27, 2011, at 11:39 PM, Christian Grobmeier wrote:

> What is the difference to Cache-Groups then?

(Also see my other email on this) 

The difference is subtle, but may be essential in some scenarios. OSCache cache groups are "tags" that can be applied to any combinations of cache keys (including multiple groups per key). E.g. on a certain event you may invalidate group1, and on some other event - group2, and these two groups may span over overlapping (but not equivalent) sets of keys. 

Using EhCache instances to emulate cache groups implies a hierarchy. All keys belong to either zero or one cache group. Now the user must ensure that 2 queries with the same cache key, but created in different places of the code are using the same group. 

This is not the end of the world of course, and I must admit that most often than not queries are actually organized this way already. 

Andrus

Re: [jira] [Commented] (CAY-1595) EHCache implementation of Provider

[Christian Grobmeier <gr...@gmail.com>]

>> There may be some difficulties with this because EHCache unlike OSCache doesn't have support for cache groups which Cayenne actively uses. As I've searched this is a major problem for all users migrating from OSCache to EHCache and EHCache even has Jira for it: https://jira.terracotta.org/jira/browse/EHC-240 .
>
> Oops. Now I am starting to remember why we picked OSCache against EHCache for Cayenne in the first place... Yeah, seems like OSCache is unique in respect to "cache groups" feature.

Isn't this the feature you are describing?
http://ehcache.org/documentation/samples.html#Using_Caches

Cache cache = manager.getCache("sampleCache1");
Element element = cache.get("key1");

If these are the groups you mean (they call it cache simply) then
there might be a chance to bridge this. You could get the cache and
iterate over all elements. If they have no "getAllElements" method,
maybe we can extend this class

>
> After a quick repeat look at EhCache after many years, it is definitely pretty advanced (I am surprised it doesn't support groups considering everything else it supports) and I see a bunch of things that I like. E.g. multiple caches per CacheManager allows to split cache into regions which seems suitable to serve for unified cache approach between object and query caches (something that's been on the list for some time). And IIRC this is how Hibernate does it.

What is the difference to Cache-Groups then?

>> The question is should we wait for EHCache to implement cache groups or write our custom solution for this? (or maybe something else)

Actually I think in the times of the cloud several options for caching
are important. Hibernate has 5 or 6 options for caching. Cayenne does
only have a cache which is not developed anymore (it would be cool if
it would go to the asf, like ognl)
>From marketing perspective - +1


> Good question... From the Jira history, this issue has been shifted around for 2 years by Terracotta, so it is hard to tell when it becomes standard.

All the other big frameworks deal with it - so there is no need to
change it. I ssaw there is even a patch ready.

> P.S. Also after joining Terracotta, EhCache became sneaky spyware: http://adammonsen.com/post/512 Big surprise :-/


This is very sad :-(

Cheers