Best practices for managing the session scope in a clustered environment?

What are the best practices for managing session variables in a clustered environment? @Simon_Goldschmidt suggested this method to perform an exclusive session lock across a cluster:

<cftransaction action="begin" isolation="serializable">
<cfquery name="sessionlock" datasource="cfsessions">
  select cfid from cf_session_data where cfid=<cfqueryparam value="#cfid#"> for update

But could this prevent Lucee from loading a session into memory on a request? Would you also need to perform some sort of read lock on session? If so, how?

Also, tomcat servlets, like the websocket extension, pass references to the user’s session scope as arguments, and therefore you cannot call lock scope="session" and you cannot run if (session.myvar == "foo") . You need to get your session variables directly out of the sessionScope argument.

I’m thinking that whatever code is used for session management should accept a session scope as an argument (defaulting to the “session” scope). Here’s my proposed API:

public any function getSessionVar(required string varName, struct sessionScope=session) {}

public any function setSessionVar(required string varName, required any value, struct sessionScope=session) {}

public boolean function deleteSessionVar(required string varName, struct sessionScope=session) {}

public boolean function sessionVarDefined(required string varName, struct sessionScope=session) {}
1 Like

Honestly, we run everything in a clustered fashion, but I’ve had lots of issues with clustered sessions. Every technique (official and hack) has run up against either performance issues or bugs in Lucee. As of now, we either use sticky sessions, or we use encrypted cookies to track users across the cluster.

There is an application property called sessionCluster that you can set to true. Then you can set a storage option to hold session data. That setup is supposed to synchronize your session data automatically between servers. It sounds great in theory, but we had issues with it in practice. However, there have been upgrades to Lucee since then, so maybe they have those bugs worked out.

This chapter gives some information about it:

1 Like

Thanks… that’s a good chapter. I would like to nail this down and get some input from the Lucee team and make sure that Lucee apps can be 100% stateless and scaled across a cluster without using sticky sessions.

I just heard that Lucee changed how it manages changes to the session in a clustered environment from v4.5 to v5, but I don’t have details. In 4.5, if two requests are being processed at the same time, one thread could overwrite changes that the other thread made… like if one thread logged the user out, the next thread could overwrite that change.

What would Lucee 5 do? Anyone know?