Is there documentation somewhere about developing cache extensions and the cache interface requirements? I'm trying to troubleshoot some issues with using the MongoDB extension as session storage, and hoping to improve / optimize the cache extension (most of it was released as beta by Andrea Capolonghi about 7 years ago and I would like to "finish it").

@seandaniels I'm not sure if there is docs to be honest

Yes, I was gonna ask you next if you'd let me peek at your MongoDB cache code 🙂

The main bits are • the Driver CFC that teaches the admin UI about the cache • the java class that implements Lucee's

Cache

interface Then you wrap it up in an extension with the right stuff in the right folders and it will install.

Yeah. The LAS mongo extension is the one I'm talking about. I've been "maintaining" it for the past few years. But the cache part of it was always beta and seems super non-optimal. But there are a lot of functions I'm just not sure why they are there.

The biggest reason we created our own Ortus extension for stuff like Mongo, Redis Couchbase, etc was that the LAS-maintained extensions weren't really 100% there and had no support really.

Heh. Yup, ok.

I can help answer questions about the Cache interface as I've spent a lot of time over he years bugging Micha about it.

The real big black box to me is how the session storage interacts with the cache. I'm seeing way more database chatter per request than I would expect.

but I can't really speak to any particular code already in the mongo extension as I'm not really familiar with it

i.e. sometimes it looks like it calls getEntry() about 4 times at the beginning of a request. And it always overwrites with cache entry at the very end with a new one (hits = 0)

There will probably be more chatter than you expect

I guess that's what I'm hoping to understand. How does the Lucee session interact with the cache. There is some very slim documentation about using a datasource as session store, but I'm not sure if that directly applies.

It's difficult to debug directly on the external cache side as the objects stored are serialized Java objects that contain the actual data

I have FusionReactor and can see in the "Relations" tab for a request all of the reads and writes to MongoDB. That's pretty helpful but that's where I'm seeing a lot of extra calls I would not expect. I have

sessionCluster=true

.

Back when I was first writing the couchbase extension, which was on Railo 4.x it was usually one get at the start of the request and one set at the end, but I think Micha stores each session key separately now

The datasource as session store docs seemed to indicate when sessionCluster is true the session data would be read at the beginning of a request and held in memory until then written back at the end of request. But I'm seeing dozens of reads/writes to the session collection per request.

Those docs were probably never updated, lol

So each key in the session scope I try to read in a request would be a separate call out to the cache? Yikes. Hm.

I think the best mileage still is to put some logging in the mongo source code that tracks the keys and values being set.

OK. That makes sense. The keys in my session store though don't look like they would support that. They are format:

lucee-storage:session:2d9cfadc-456e-4586-abdb-f6b966d34b7a:dealstream-com

where the UUID there is the CFID value. Maybe that's a problem with the cache extension though.

I doubt you'll find a useful ticket that represents the addition. It's probably just committed under a generic ticket labeled "improve caching" 😆

OK. Well, thanks for the sanity check anyway. If you do happen to recall anything that talks about this I'd be psyched to see anything that sheds light on it. Otherwise yeah I'll start adding some log/debug stuff.

hmm, well that doesn't support the theory of having a separate item for each key, but he was talking about doing that after I had developed the couchbase extension and I never really dug back into the code at a deep level after that

Yep

Just re-read the comment thread on that one. Geez, just a disappointing and ridiculously unnecessary discussion 😕

Interesting. By the way, this app does use the

sessionStorage@cbstorages

module exclusively for session data so your comment about that in the ticket is probably quite relevant

Micha did ask for feedback on what improvements you'd like for the cache interfaces on the mailing list, but @bdw429s you didn't respond yet. We are chatting in a temporal black hole here, post to the mailing list!

I'm aware and it's on my list of things to look at.

Zac, thanks I will start a thread or try to join an existing thread there as well.

Sadly, most of that conversation happened years ago over Skype with Micha!