<< Back to previous view

[CCACHE-25] TTLCache appears to have inconsistent behavior with respect to the TTL parameter Created: 02/Aug/12  Updated: 14/Aug/12  Resolved: 14/Aug/12

Status: Resolved
Project: core.cache
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: David Santiago Assignee: Fogus
Resolution: Completed Votes: 0
Labels: None


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> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(has? :a))
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(get :a))

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).

Comment by David Santiago [ 14/Aug/12 6:39 PM ]

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.

Comment by Fogus [ 14/Aug/12 8:33 PM ]

Fixed in v0.6.2

Generated at Thu Jan 18 08:23:38 CST 2018 using JIRA 4.4#649-r158309.