Clojure Q&A - Recent activity in core.cache

Closed: Could some calls to clojure.core/= be replaced by clojure.core/identical?

Thu, 26 Feb 2026 17:09:09 +0000

I'm using core.cache in combination with LazyMap. Lazy maps are map-like objects (new data type encapsulating maps and adding some logic to auto-force delayed values associated with keys).

When I started putting lazy maps as values of FIFO Cache I observed that all values are being realized just after the map lands in cache. After some digging I've found that it is caused by expression (= ::expired v) in clojure.core.cache.wrapped/lookup-or-miss.

What happens is that = internally calls clojure.lang.Util/equiv (since LazyMap implements IPersistentCollection) and then, after some dispatching, equiv is called to check whether the contents of a lazy map equals to other object (implicitly other map). This is the desired behavior and lazy map realizes all values to make comparison possible.

However, when comparing a map-like object to something which is not a map (nor a collection), short-circuit would be welcome as soon as we know that it will for sure return false. But changing that is probably more related to Clojure itself and things like CLJ-1375.

What could be done on core.cache's side, if that's not too problematic, would be a replacement of

(= ::expired v) with (identical? ::expired v)

in clojure.core.cache.wrapped.

It would not only fix corner cases like mine but also speed things up a bit (explicit referential equality rocks when it comes to Clojure keywords).

Other expressions where that could be changed (just in case) are:
(= ::nope ret) and (= ::nil v) from clojure.core.cache.

Closed: clojure.core.cache caches delays that hold exceptions as of version 1.2.254

Thu, 26 Feb 2026 02:49:10 +0000

As of version 1.2.254 of org.clojure/core.cache, using a value-fn that throws will cause an entry to be added to the cache associated with a Delay with :status :failed and the exception as a value.

The code below can be used to compare the behavior between versions 1.1.234 and 1.2.254.

(require '[clojure.core.cache.wrapped :as cw])

(def counter (atom 0))

(defn value-fn [v]
  (prn :value-fn-called)
  (swap! counter inc)
  (if (= @counter 1)
    (throw (ex-info "thrown" {}))
    v))

(def test-cache (cw/lu-cache-factory {} :threshold 10))

(reset! counter 0)
; this will throw
(cw/lookup-or-miss test-cache "throw" value-fn)
; in 1.1.234 this will call value-fn again and not throw; in 1.2.254, it won't call and return
; the cached delay result, which is an exception
(cw/lookup-or-miss test-cache "throw" value-fn)

; evict to force call to value-fn
(cw/evict test-cache "throw")

This is related to work done in CCACHE-65 to avoid cache stampede in multi-threaded applications, and could be related to what has been reported in CMEMOIZE-31.

This was initially reported in Clojurians Slack.

Commented: Multi-threaded cache stampede in core.cache

Mon, 23 Feb 2026 20:15:14 +0000

This (relatively new) behavior took as by surprise in one (probably quite niche) use case. We had been using 1.1.234 for a long time, and just upgraded to 1.2.254.

Some of our unit tests[1] broke, because now doing a `get` on the (deref-ed) cache atom with a key wouldn't return the value associated with the key, but the delay that wrapped it. It took as a bit to realize what was going on.

Nothing serious, just to let other people know in case the hit the same use case as we did.

[1] In https://github.com/gethop-dev/buddy-auth.jwt-oidc/

Closed: Core Cache and Count

Mon, 23 Feb 2026 15:06:07 +0000

Hi,

I notice that in the wrapped namespace of core.cache, there is a has? function that checks the wrapped cache if it has an element or not. It does this by delegating to the underlying cache c/has? function of the wrapped cache.

For reporting purposes, I need to get the current size of the cache (with the caveat of course that the size could be approximate, given the particular nature of a particular cache - but approximation is fine).

Unfortuantely, a size or count function doesn't exist in the wrapped namespace, it only exists on the wrapped cache itself - thus doing:

(count @wrapped-cache)

does return the value.

It would be good, however, if there was also a similar function in the wrapped namespace, something like this (using size as the function name, but could be something else):

(defn size
   [cache-atom]
   (c/count @cache-atom)

The rationale being that having this function exposed in the wrapped namespace keeps the code consistent - i.e., whilst I can continue to do:

(count @wrapped-cache)

It would more preferrable to keep using the wrapped namespace (as I do with other operations, such as evict), i.e., something along the lines of:

(wrapped/size wrapped-cache)

Do you think this suggestion might be something that could be included in the wrapped namespace?

Thank you.

-=david=-

Commented: Is the clojure.cache behavior for lookup-or-miss value-fn re-entrancy broken or am I misunderstanding the docstring?

Fri, 15 Aug 2025 22:55:47 +0000

This works, but it has the unfortunate side-effect of allowing errors into the cache.

Example:

```clojure
;; Put an error in the cache with the default lookup-or-miss
(is (thrown? Exception
             (cache/lookup-or-miss cache-atom :wrapped (fn [_]
                                                         (throw (Exception. "oops"))))))

;; Now we'll never get that error out of the cache
(is (thrown? Exception
             (cache/lookup-or-miss cache-atom :wrapped (fn [_] :ok)))))
```

Here is a potential fix that removes errors from the cache:

```clojure
(defn lookup-or-miss
  "Retrieve the value associated with `e` if it exists, else compute the
  value (using value-fn, and optionally wrap-fn), update the cache for `e`
  and then perform the lookup again.
  value-fn (and wrap-fn) will only be called (at most) once even in the
  case of retries, so there is no risk of cache stampede.
  Since lookup can cause invalidation in some caches (such as TTL), we
  trap that case and retry (a maximum of ten times)."
  ([cache-atom e value-fn]
   (lookup-or-miss cache-atom e default-wrapper-fn value-fn))
  ([cache-atom e wrap-fn value-fn]
   (let [d-new-value (delay (wrap-fn value-fn e))
         res (loop [n 0
                    v (c/lookup (swap! cache-atom
                                       c/through-cache
                                       e
                                       default-wrapper-fn
                                       (fn [_] d-new-value))
                                e
                                ::expired)]
               (when (< n 10)
                 (if (= ::expired v)
                   (recur (inc n)
                          (c/lookup (swap! cache-atom
                                           c/through-cache
                                           e
                                           default-wrapper-fn
                                           (fn [_] d-new-value))
                                    e
                                    ::expired))
                   v)))]
     (if (identical? res d-new-value)
       (try
         (force res)
         (catch Throwable t
           (swap! cache-atom
                  (fn [a]
                    (if (and (c/has? a e)
                             (identical? d-new-value (c/lookup a e)))
                      (c/evict a e)
                      a)))
           (throw t)))
       (force res)))))
```

Commented: clojure.core.cache/TTLCache not extending TTL on hit?

Tue, 02 Jan 2024 17:24:54 +0000

Alright, I will just re-`assoc` on lookup (which is I am currently doing). Thanks for the reply and clarification!

Closed: Suggest using (fn [& args] x) over constantly in README.md

Sat, 18 Mar 2023 22:53:00 +0000

Was misled by the example in the README.md the other day.

I did the equivalent of the following
(w/lookup-or-miss C3 :b (constantly (do (Thread/sleep 1000) 42)))

instead of

(w/lookup-or-miss C3 :b (fn [& args] (do (Thread/sleep 1000) 42)))

Resulting in the IO call I was doing which takes the place of (Thread/sleep 1000) to always be evaluated. This resulted in a "cache" that returns the value from the cache but will always trigger the call

Commented: Docs for core.cache.documentation are ambigous

Sun, 12 Feb 2023 01:14:00 +0000

I've added some notes to the README (and to a couple of the /docs pages in the repo) to try to clarify the two styles of usage: https://github.com/clojure/core.cache/blob/master/README.md

In particular, I changed the :as alias for clojure.core.cache.wrapped to w (from c) so it's clearer that the second block of examples all uses the wrapped API.

Answer selected: Could there be a ClojureScript version of core.cache?

Sun, 04 Sep 2022 22:18:02 +0000

I would personally welcome a plan for CLJS core.cache. I think that instead of reopening that tickets I 'd like to look at it from the perspective of CCACHE-55 and how we could design a library that works across langs.

Answered: Issues with LRU and LU cache in core.cache

Tue, 27 Jul 2021 13:08:32 +0000

I would certainly be willing to accept a patch. I will look into getting you Jira access today.

As for the tie-breakers I need to look at the code again to reload context but I suspect that comment is unnecessary and should be removed.

Commented: Why do core.cache's deftypes not implement equality?

Fri, 26 Mar 2021 12:19:10 +0000

Thank you! These are useful insights.

Accordingly I ended up implementing a thin wrapper for ensuring that one uses the right methods and only can access the underlying data in a safe way.

Merely as an observation, I wonder if changing deftype->defrecord would have helped here?

Commented: core.cache: TTLCacheQ timer is not monotonic

Sat, 13 Mar 2021 03:57:19 +0000

Thanks, John. I'll have a read through all of this when I go back to working on core.cache next.

Answered: Suggested usage subject to Cache Stampede

Tue, 27 Aug 2019 20:41:52 +0000

This is fixed in org.clojure/core.cache "0.8.1" with the addition of the clojure.core.cache.wrapped namespace and, in particular, the new lookup-or-miss function in that namespace.

Answered: Add ARC or CAR algorithm