Pre-loading entry from a persistent store after it has been evicted/expired/removed+skipStore

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

Pre-loading entry from a persistent store after it has been evicted/expired/removed+skipStore

Denis Magda
Igniters,

Let's say that we have the following task. Due to RAM memory constraints
we need to evict entries from a cache.
Presently it can be done with:
1) eviction to swap;
2) expire policy;
3) eviction policy;
4) remove(key) + withSkipStore;

After an entry gets evicted from cache we may need to get it in the
future using cache.get(...) operation.
I've tried to use approaches 2, 3, 4 in conjunction with a persistent
store but the store never gets called when I try to get an entry that
was evicted before.
Is this considered behavior? Don't we want to improve the situation
around here?

Approach #1 sure works fine and I don't need a persistent storage there.
But actually there can be big data set of old, historical entries that
were evicted and I want avoid iteration over them when SQL, Scan or any
other kind of queries is executed.

--
Denis


Reply | Threaded
Open this post in threaded view
|

Re: Pre-loading entry from a persistent store after it has been evicted/expired/removed+skipStore

yzhdanov
Did you try setting
javax.cache.configuration.MutableConfiguration#isReadThrough? Or you
claiming it is not working?

--Yakov

2016-03-31 11:16 GMT+03:00 Denis Magda <[hidden email]>:

> Igniters,
>
> Let's say that we have the following task. Due to RAM memory constraints
> we need to evict entries from a cache.
> Presently it can be done with:
> 1) eviction to swap;
> 2) expire policy;
> 3) eviction policy;
> 4) remove(key) + withSkipStore;
>
> After an entry gets evicted from cache we may need to get it in the future
> using cache.get(...) operation.
> I've tried to use approaches 2, 3, 4 in conjunction with a persistent
> store but the store never gets called when I try to get an entry that was
> evicted before.
> Is this considered behavior? Don't we want to improve the situation around
> here?
>
> Approach #1 sure works fine and I don't need a persistent storage there.
> But actually there can be big data set of old, historical entries that were
> evicted and I want avoid iteration over them when SQL, Scan or any other
> kind of queries is executed.
>
> --
> Denis
>
>
>