core.cache

TTLCache appears to have inconsistent behavior with respect to the TTL parameter

Details

  • Type: Defect Defect
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

There appears to be some inconsistency in the implementation of TTLCache. Specifically, it appears that if you lookup a value whose TTL has expired, but no new items have been added to the cache, it will still be present. But if you ask if the cache has? the value, it will report that it does not. For example:

```
user> (defn sleepy [e t] (Thread/sleep t) e)
#'user/sleepy
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(has? :a))
false
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(get :a))
1
```

So here we see, has? reports the value is no longer in the cache, but get will still give you the value. Unless I am misunderstanding the purpose or contract of these two functions, it seems that they should agree in whether or not a value is in the cache.

This also brings up the question of whether a value in a TTL cache that has passed the TTL should remain in the cache until the cache is updated. My expectation was that an item is not in the cache after the TTL has passed (ie, has? is currently correct). I can also see the argument that the TTL parameter is merely a lower bound on the amount of time it is cached; if it can be accommodated for longer, it will be (and thus lookup is currently correct).

As I said, my expectation was that things are no longer in the cache after the TTL, and I would still vote for this behavior as the correct one for a TTL cache, as it seems like a reasonable cache to use for things that can change out from under you, but a short period where it is out of date is acceptable (which is how I was trying to use it).

Activity

Hide
Fogus added a comment -

Fixed in v0.6.2

Show
Fogus added a comment - Fixed in v0.6.2
Hide
David Santiago added a comment -

core.cache 0.6.2 fixes this issue for me; the call to get in the code above now returns 'nil' to match the false return from has?. I'd close the issue if I could.

Thanks Fogus.

Show
David Santiago added a comment - core.cache 0.6.2 fixes this issue for me; the call to get in the code above now returns 'nil' to match the false return from has?. I'd close the issue if I could. Thanks Fogus.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: