CACHEBOX question?? Im not sure if this is the wrong way to think about caching. But here we go. I have API requests that I am using throughout client based SAS product, some of which are intensive database requests that take longer than i would like (1-2 seconds), I have optimized the queries to the best of my ability and now I would like to entertain caching. My problem is it appears in caching most cached items are invalidated based on usage or time. However I need them to be invalidated by triggering an update when the clients settings are changed. Is this an anti-pattern or just not a common workflow. I imagine most caching workflows are for front facing sites that don’t change often. Either way a good workflow to use for invalidating on a user changing their data would be super helpful to me?

well I would assume you would want it invalidated upon them changing the data. I typically do this upon settings changes then the next call for that data gets cached again.

@Scott Steinbeck There are two ways something can leave the cache • the eviction policy removes it (based on whatever logic you want) • You remove it manually because your app code has determined it's stale

Yep, thats my approach, using an interceptor and having good naming conventions for cached items. Brad is just better at giving thorough explanation of course lol

This is also implemented in contentbox

In a meeting, thank you for all the feedback, ill read through it in 20 minutes

Just a note on the points above, when caching something forever (time-wise) and evicting it when another action happens in your application is perfectly fine. Make sure the cache provider you are using does not evict items out if they are not accessed within a certain amount of time (unless you want that).

Thanks all, i will dig into content box and try implementing a similar pattern. @bdw429s on your point about clear by snippet, is that something that is available in the

ConcurrentStore

or something I would need to implement myself?

@Scott Steinbeck

expireByKeySnippet()

is part of the

CacheBoxProvider

so it should work with the concurrentstore.

oh gotcha, ill have to check out the source, I missed that one in the docs

Well, it's not part of the

ICacheProvider

interface, so you can't asssume it will be there unless your provider is a subclass of

AbstractCacheBoxProvider

let me ask the question a different way, for my use case, since i am not going the way of couchdb or redis, is there a preferred/more performant cache to use?

Both of those use the underlying CFML

cacheGet()

cachePut()

BIFs, etc. The Lucee one just supports Lucee better

ok good to know!

An in memory cache also eliminates issues serializing complex objects which can be a blessing and a curse

Just spin up Redis, its badass, fast and efficient

if most of the things i will be caching are json api responses, does using the

concurrent soft reference

vs.

concurrent store

have any functional difference?

If you don't care if a given item drops from the cache, no

oh ok, i see the advantage

The concurrent store will just fill up your heap until it dies!

oh good to know

Luis set those default sizes many years ago

beautiful

Pretty much

is there a benefit to using

expireByKeySnippet

over

clearByKeySnippet

expire just marks the cache key as expired so it will be reaped the next time reaping runs. Clear actually removes from the cache right then

I would imagine the work might be less since its lazily deleting the cached item unless its reaped

Correct, actually removing an item from the cache involves update the indexer pool metadata

cool, that makes sense

That's called ColdBox's event caching 🙂

perfect, ive recreated the wheel 😛

No

oh ok