QueryCache scope

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

QueryCache scope

Lon Varscsak
Hey all,

I would have bet large sums of money that a custom implementation of
QueryCache would result in a new QueryCache object per context (local).
However, it looks like a NestedQueryContext gets created and only one
instance of the specified QueryCache is created (in DataContextFactory).

I'd really love to have local caches dumped when the ObjectContext goes
away (assuming it's a localCache).  Is this possible?  Thoughts?

Thanks!

-Lon
Reply | Threaded
Open this post in threaded view
|

Re: QueryCache scope

Andrus Adamchik
NestedQueryCache is created per ObjectContext. The underlying data is stored in the common cache, prefixed with unique key. While that data is not actively removed from the cache when the ObjectContext (and its NestedQueryCache) go out of scope, it should not affect the overall cache performance. Since most caches have an LRU policy, those abandoned entries will eventually be pushed out of the cache, replaced by more recent entries from other contexts.

Andrus

> On Nov 9, 2017, at 2:08 AM, Lon Varscsak <[hidden email]> wrote:
>
> Hey all,
>
> I would have bet large sums of money that a custom implementation of
> QueryCache would result in a new QueryCache object per context (local).
> However, it looks like a NestedQueryContext gets created and only one
> instance of the specified QueryCache is created (in DataContextFactory).
>
> I'd really love to have local caches dumped when the ObjectContext goes
> away (assuming it's a localCache).  Is this possible?  Thoughts?
>
> Thanks!
>
> -Lon

Reply | Threaded
Open this post in threaded view
|

Re: QueryCache scope

Lon Varscsak
In the case of using a more specific cache (like discussed in the other
thread), the problem is these “small” caches get abandoned.  The
documentation says “localCache” is bound to the ObjectContext, but that
doesn’t appear to be true.

-Lon

On Wed, Nov 8, 2017 at 11:22 PM, Andrus Adamchik <[hidden email]>
wrote:

> NestedQueryCache is created per ObjectContext. The underlying data is
> stored in the common cache, prefixed with unique key. While that data is
> not actively removed from the cache when the ObjectContext (and its
> NestedQueryCache) go out of scope, it should not affect the overall cache
> performance. Since most caches have an LRU policy, those abandoned entries
> will eventually be pushed out of the cache, replaced by more recent entries
> from other contexts.
>
> Andrus
>
> > On Nov 9, 2017, at 2:08 AM, Lon Varscsak <[hidden email]> wrote:
> >
> > Hey all,
> >
> > I would have bet large sums of money that a custom implementation of
> > QueryCache would result in a new QueryCache object per context (local).
> > However, it looks like a NestedQueryContext gets created and only one
> > instance of the specified QueryCache is created (in DataContextFactory).
> >
> > I'd really love to have local caches dumped when the ObjectContext goes
> > away (assuming it's a localCache).  Is this possible?  Thoughts?
> >
> > Thanks!
> >
> > -Lon
>
>
Reply | Threaded
Open this post in threaded view
|

Re: QueryCache scope

John Huss
It is connected to the context in the sense that query results that are
localCached in one context will not be retrieved from the cache by another
context (but instead hit the DB).  However, the objects themselves may
continue to reside in memory indefinitely until memory pressure causes them
to be removed or the cache expires due to a timeout.

On Thu, Nov 9, 2017 at 10:40 AM Lon Varscsak <[hidden email]> wrote:

> In the case of using a more specific cache (like discussed in the other
> thread), the problem is these “small” caches get abandoned.  The
> documentation says “localCache” is bound to the ObjectContext, but that
> doesn’t appear to be true.
>
> -Lon
>
> On Wed, Nov 8, 2017 at 11:22 PM, Andrus Adamchik <[hidden email]>
> wrote:
>
> > NestedQueryCache is created per ObjectContext. The underlying data is
> > stored in the common cache, prefixed with unique key. While that data is
> > not actively removed from the cache when the ObjectContext (and its
> > NestedQueryCache) go out of scope, it should not affect the overall cache
> > performance. Since most caches have an LRU policy, those abandoned
> entries
> > will eventually be pushed out of the cache, replaced by more recent
> entries
> > from other contexts.
> >
> > Andrus
> >
> > > On Nov 9, 2017, at 2:08 AM, Lon Varscsak <[hidden email]>
> wrote:
> > >
> > > Hey all,
> > >
> > > I would have bet large sums of money that a custom implementation of
> > > QueryCache would result in a new QueryCache object per context (local).
> > > However, it looks like a NestedQueryContext gets created and only one
> > > instance of the specified QueryCache is created (in
> DataContextFactory).
> > >
> > > I'd really love to have local caches dumped when the ObjectContext goes
> > > away (assuming it's a localCache).  Is this possible?  Thoughts?
> > >
> > > Thanks!
> > >
> > > -Lon
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: QueryCache scope

Lon Varscsak
Yeah, I guess I think that's misleading, but I understand now.  I have my
on query cache class and was doing something tricky with session ids in the
keys (to get the effect we were talking about in the other thread), but
that's when I realized this isn't good unless you have a timeout too.

What's the purpose for a unique NestedQueryCache and not just a unique
QueryCache per context?  I'm sure there's a reason, but not sure what the
benefit is.

-Lon

On Thu, Nov 9, 2017 at 12:24 PM, John Huss <[hidden email]> wrote:

> It is connected to the context in the sense that query results that are
> localCached in one context will not be retrieved from the cache by another
> context (but instead hit the DB).  However, the objects themselves may
> continue to reside in memory indefinitely until memory pressure causes them
> to be removed or the cache expires due to a timeout.
>
> On Thu, Nov 9, 2017 at 10:40 AM Lon Varscsak <[hidden email]>
> wrote:
>
> > In the case of using a more specific cache (like discussed in the other
> > thread), the problem is these “small” caches get abandoned.  The
> > documentation says “localCache” is bound to the ObjectContext, but that
> > doesn’t appear to be true.
> >
> > -Lon
> >
> > On Wed, Nov 8, 2017 at 11:22 PM, Andrus Adamchik <[hidden email]
> >
> > wrote:
> >
> > > NestedQueryCache is created per ObjectContext. The underlying data is
> > > stored in the common cache, prefixed with unique key. While that data
> is
> > > not actively removed from the cache when the ObjectContext (and its
> > > NestedQueryCache) go out of scope, it should not affect the overall
> cache
> > > performance. Since most caches have an LRU policy, those abandoned
> > entries
> > > will eventually be pushed out of the cache, replaced by more recent
> > entries
> > > from other contexts.
> > >
> > > Andrus
> > >
> > > > On Nov 9, 2017, at 2:08 AM, Lon Varscsak <[hidden email]>
> > wrote:
> > > >
> > > > Hey all,
> > > >
> > > > I would have bet large sums of money that a custom implementation of
> > > > QueryCache would result in a new QueryCache object per context
> (local).
> > > > However, it looks like a NestedQueryContext gets created and only one
> > > > instance of the specified QueryCache is created (in
> > DataContextFactory).
> > > >
> > > > I'd really love to have local caches dumped when the ObjectContext
> goes
> > > > away (assuming it's a localCache).  Is this possible?  Thoughts?
> > > >
> > > > Thanks!
> > > >
> > > > -Lon
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: QueryCache scope

Andrus Adamchik
> What's the purpose for a unique NestedQueryCache and not just a unique
> QueryCache per context?  I'm sure there's a reason, but not sure what the
> benefit is.

Proxying multiple nested caches on top of a single app-wide cache allows to implement central management of the app memory use and data refresh/expiration strategies. One example of what that means is you can balance your JVM -Xmx setting and the size of the cache to ensure the app never runs out of memory regardless of the load. With query cache often being the biggest single memory hog in the entire application this is important.

Andrus


> On Nov 9, 2017, at 11:21 PM, Lon Varscsak <[hidden email]> wrote:
>
> Yeah, I guess I think that's misleading, but I understand now.  I have my
> on query cache class and was doing something tricky with session ids in the
> keys (to get the effect we were talking about in the other thread), but
> that's when I realized this isn't good unless you have a timeout too.
>
> What's the purpose for a unique NestedQueryCache and not just a unique
> QueryCache per context?  I'm sure there's a reason, but not sure what the
> benefit is.
>
> -Lon
>
> On Thu, Nov 9, 2017 at 12:24 PM, John Huss <[hidden email]> wrote:
>
>> It is connected to the context in the sense that query results that are
>> localCached in one context will not be retrieved from the cache by another
>> context (but instead hit the DB).  However, the objects themselves may
>> continue to reside in memory indefinitely until memory pressure causes them
>> to be removed or the cache expires due to a timeout.
>>
>> On Thu, Nov 9, 2017 at 10:40 AM Lon Varscsak <[hidden email]>
>> wrote:
>>
>>> In the case of using a more specific cache (like discussed in the other
>>> thread), the problem is these “small” caches get abandoned.  The
>>> documentation says “localCache” is bound to the ObjectContext, but that
>>> doesn’t appear to be true.
>>>
>>> -Lon
>>>
>>> On Wed, Nov 8, 2017 at 11:22 PM, Andrus Adamchik <[hidden email]
>>>
>>> wrote:
>>>
>>>> NestedQueryCache is created per ObjectContext. The underlying data is
>>>> stored in the common cache, prefixed with unique key. While that data
>> is
>>>> not actively removed from the cache when the ObjectContext (and its
>>>> NestedQueryCache) go out of scope, it should not affect the overall
>> cache
>>>> performance. Since most caches have an LRU policy, those abandoned
>>> entries
>>>> will eventually be pushed out of the cache, replaced by more recent
>>> entries
>>>> from other contexts.
>>>>
>>>> Andrus
>>>>
>>>>> On Nov 9, 2017, at 2:08 AM, Lon Varscsak <[hidden email]>
>>> wrote:
>>>>>
>>>>> Hey all,
>>>>>
>>>>> I would have bet large sums of money that a custom implementation of
>>>>> QueryCache would result in a new QueryCache object per context
>> (local).
>>>>> However, it looks like a NestedQueryContext gets created and only one
>>>>> instance of the specified QueryCache is created (in
>>> DataContextFactory).
>>>>>
>>>>> I'd really love to have local caches dumped when the ObjectContext
>> goes
>>>>> away (assuming it's a localCache).  Is this possible?  Thoughts?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -Lon
>>>>
>>>>
>>>
>>