Participating Frequently

Question

Session variables being overwritten when using Redis for session storage

Forum|Forum|10 months ago
March 28, 2025
2 replies
2475 views

Would greatly appreciate if someone could comment on this snippet from the external session storage doc:
Once a session object is received from Redis, there can be changes to the object within the timespan of a given request. The session is persisted (if modified) back to external storage on request end. The changes made by the current request on one node are available to all other nodes.
https://helpx.adobe.com/coldfusion/using/external-session-storage.html

As part of my organization's move to a cluster of cf server instances, we're also moving to storing sessions in a redis cache. Some places in the app make remote invocations via fetch request to first modify the session in some way, then before that request has finished, re-fetch some data which may or may not use the newly modified state. This was fine while we were storing session in memory, but we're finding that the modified state is getting overwritten by the second request (perhaps because that second request pulls from the cache before it was modified by the first request). This is all happening on 1 server using the cache, as we haven't moved to the cluster yet.

Ideally, we'd make 1 single request that does both, but going through our huge legacy app to find where this might happen would be a nightmare. I'm wondering if our situation is something other people have seen--because the documentation makes it seem like the modified session should be available to both requests?

BKBK

Community Expert

I have been scratching my head on this one. I thought it was straightforward. But your question suggests otherwise. So let's see if I understand your question.

User's session is in progress. User makes request 1, during which the value of session.myVar is changed from session.myVar=50 to session.myVar=5000. User then makes request 2, during which the session scope is dumped.

Do you mean that session.myVar is currently 50 instead of 5000?

If so, two possible causes could be:

Request 1 had not yet ended, hence the cached session had not been updated.
Sticky Sessions have not been disabled.

BKBK

Community Expert

If those were the causes, then the corresponding solutions would be:

Place within a session-scoped lock any code that writes to or reads from a session. For example,

<cflock scope="session" timeout="30" type="exclusive">
   <cfset session.myVar = getIt()>        
</cflock>

<cflock scope="session" timeout="10" type="readonly">
   <cfset updatedValue = updatedValue + session.myVar>        
</cflock>

Disable "Sticky Sessions" and "Session Replication". I would then restart the instances, just to be sure.

Z

zachary_3780Author

Participating Frequently

Thanks for the help--I don't believe sticky sessions/session replication is pertinent in this current case, because we are still only running on one server.

In my previous debugging, I was able to log session.myVar in the application.onRequestEnd hook. E.g., if session.myVar is initialized as 0 and the first request should set session.myVar to 1, the first log of session.myVar is 1 (the variable was set correctly), but the second log of session.myVar is 0. I had interpreted this to be the first cause you had listed--the first request had not finished before the second one had started and by the time the second is finished, the session state has changed. It appears that the requests only share session variables through redis, so the updated variable will only be available to request 2 once it has written to redis. In other words, "The changes made by the current request on one node are available to all other nodes" ...but changes are not available to other requests on the same node.

I'm rereading "The session is persisted (if modified) back to external storage on request end." and I'm curious on how coldfusion determines if the session has been modified--session.myVar was not directly modified by the second request, but my guess is that, since the value of myVar is different, it will persist and overwrite myVar in the redis cache. I don't think cflock will help because I don't modify session.myVar at all in request 2--but the value has changed since the request started.

Charlie Arehart

Community Expert

First, (since you've asked) I'll offer that I've not heard of anyone hitting this, meaning who's using the app design you use and then switches to redis sessions.

But second, I'd argue that the quote from the docs is specifically speaking TO that concern you raise, in their clarifying that the session changes in the current request are not written back to redis until "request end". And it makes sense: otherwise cf would need to be writing to (and reading from) redis somehow THROUGHOUT the entire request, which would be expensive/chatty. 🙂

I can't fathom what can resolve this, as far as any feature in cf.

(Edit after original post:) Well, there is the older "session Replication" feature, which cf has longer offered-- though configurable in the cf admin only as part of cf's clustering feature, which you don't mention using. (FWIW, the session replication CAN be made to work without that CF clustering feature--and even in cf Standard--by editing files instead of using the CF admin. That's not documented anywhere I can readily point to.) But the session replication is itself very chatty, which made some not care for it, among other reasons.

Maybe others will have better ideas for you.

/Charlie (troubleshooter, carehart. org)

Z

zachary_3780Author

Participating Frequently

Thanks for the input, Charlie--and you're probably right that reading and writing to redis throughout the request would be expensive. Part of what I was hoping (perhaps beyond reason haha) was that during request 2, coldfusion would recognize that the user's session was already pulled during request 1 and use the session state from temporary memory that was modified in request 1.

Perhaps I misinterpreted the last part of that paragraph, "The changes made by the current request on one node are available to all other nodes." This is probably referring to multiple cf server instances accessing the same redis cache, rather than multiple requests accessing the changes made mid-request.

Charlie Arehart

Community Expert

Glad to have helped. And right: I'd read that quote also as just them helping folks connect the dots that a given app running in multiple cf instances or servers CAN share sessions using this redis feature, if they all point to the same redis server.

But again there may well be some way to get what you want. Since Adobe has not chimed in, you may want to ask them at cfsup@adobe.com. If you learn anything new, do let us know! 🙂

(As for bkbk's reply below, I'll leave you to consider and respond to it.)

/Charlie (troubleshooter, carehart. org)

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded