In the admin, the choices for session storage are memory, file, cookie and a database, if you have one set up. But the explanations are confusing, and I can find nothing in the docs explaining the choices.
The explanation for “memory” says “no persistent storage,” which sounds like no session storage at all, though it’s hard to believe it means that.
Could someone please explain the choices a bit better, and which to use for the traditional “storage in memory on the server, cookie on the client side” setup?
Persistent just means stored somewhere outside of the server’s RAM such that it would be kept if you restarted the server. A DB table, or a Cache would be persistent.
I think the help on the page does a pretty decent job of describing each one:
I’m not entire sure I understand your second question. At the end of the day, you use whatever storage mechanism suits your needs. If you have a single server, or a load balancer using sticky settings, and are ok with sessions going away if you restart the Lucee service, then memory is the easiest method and will work fine. If you have a cluster of servers and want to round robin users on them and/or want a service restart to not blow away people’s logins/shopping cart/etc then use a persistent storage.
As far as your reference to cookies, note the cookie storage is inherently insecure and doesn’t even work if you put non-serializable objects in session (seems like a bug). And that said, it is also typical to use cookies on the client to store the session identifiers (CFID/JSessionID) but that’s really irrespective of the backend storage mechanism.
At Ortus, we use deployments on Docker swarm and store our sessions in a Couchbase Cache Cluster via the Ortus Lucee Couchbase Cache Extension. But that’s just what works best for us.
