Just to push to the limit.
Lets say we saved/serializer the cache to a secondary storage (file or
ZooKeeper).
What happen when the cache is restored?
I mean TTL is still honored? expired data while been sleeping will be
evicted upon an operation is performed after deserialization?
Thanks a lot
> And thank you Mr. Fogus.
Don't thank me, Sean did all the hard work. :-)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patien
Thank you, I understand it :)
And thank you Mr. Fogus. What a great pleasure!
On Tuesday, October 23, 2012 1:42:28 AM UTC+3, Sean Corfield wrote:
>
> On Mon, Oct 22, 2012 at 3:30 PM, Hussein B. >
> wrote:
> > So we need to call evict explicitly if we want to remove an entry? no
> > automatic de
On Mon, Oct 22, 2012 at 3:30 PM, Hussein B. wrote:
> So we need to call evict explicitly if we want to remove an entry? no
> automatic deletion after expiring?
The cache is immutable.
When you call hit / miss, you get a new instance of the cache with the
expired entries removed, and the hit entr
I see, it works now.
So we need to call evict explicitly if we want to remove an entry? no
automatic deletion after expiring?
On Tuesday, October 23, 2012 1:21:54 AM UTC+3, Sean Corfield wrote:
>
> On Mon, Oct 22, 2012 at 3:08 PM, Hussein B. >
> wrote:
> > I tried this:
> >
> > (defn hit-or-
On Mon, Oct 22, 2012 at 3:08 PM, Hussein B. wrote:
> I tried this:
>
> (defn hit-or-miss
> [a k v]
> (if (c/has? @a k)
> (c/hit @a k)
> (c/miss @a k v)))
My bad... got a bit carried away with the derefs based on code I was
playing around with in the REPL. Try this:
(defn hit-or-miss
I tried this:
(defn hit-or-miss
[a k v]
(if (c/has? @a k)
(c/hit @a k)
(c/miss @a k v)))
(def acu (atom (c/ttl-cache-factory {} :ttl 2)))
(swap! acu hit-or-miss :e 55)
But I got:
ClassCastException clojure.core.cache.TTLCache cannot be cast to
clojure.lang.IDeref clojur
Just to clarify, hit does nothing for TTL (since items timeout based
solely on when they were added, not when they were last touched), so
swap! on the hit really makes no difference here. It would, however,
be required for some of the other types of cache.
Also, exactly how you use has? / hit / mi
On Mon, Oct 22, 2012 at 1:50 PM, Hussein B. wrote:
> c3 holds a map containing {:a 1} that will lives for two minutes.
In the code I provided, c3 is an atom that holds a cache (which is the map).
> After two minutes, requesting :a is generating false since it reached its
> TTL but it will still
I see.
But I didn't really grasp the whole concept firmly .
c3 holds a map containing {:a 1} that will lives for two minutes.
After two minutes, requesting :a is generating false since it reached its
TTL but it will still live in map until it is removed explicitly by
invoking evict.
Correct?
Als
On Mon, Oct 22, 2012 at 12:05 PM, Michael Fogus wrote:
> First, thanks for trying c.c.cache! The answer to your question is
> that the TTL cache implementation is non-destructive. The `evict`
> call returns the cache without the element, but does not remove it
> from the original cache.
In other
Wow, What an honor to get a reply from my idol and mentor !!
Thanks a lot.
I really appreciate to hear your opinion regarding this:
http://stackoverflow.com/questions/13015906/is-it-safe-to-use-a-clojure-core-cache-guarded-by-ref-type
Every thing started with this issue.
Appreciate your precious ti
> What I'm missing?
First, thanks for trying c.c.cache! The answer to your question is
that the TTL cache implementation is non-destructive. The `evict`
call returns the cache without the element, but does not remove it
from the original cache.
--
You received this message because you are subsc
13 matches
Mail list logo
