2

I have always used the session scope in my cfml application to do things like store the currently logged in user object. It's great!

user.isLoggedIn(), user.hasPremiumAccess(), user.hasRole('admin')

In attempting to migrate my application to a clustered (cloud) environment, I realize that relying on the session scope is less than ideal since each instance of the running application has its own server memory. I know I could use "sticky sessions," but I would rather not since that would restrict something like Amazon Elastic Beanstalk from freely spinning up and down instances of the application (based on load).

I also know I could use the client scope to store simple values in a cluster-friendly way, but what about complex data, like the user object I described? How would you store the user object, or what other approach might I use?

I can make application changes as needed.

** EDIT ** to be clear, it's not that I CAN'T use sticky sessions, it's that I don't WANT to use sticky sessions (or session replication). The reason is so that I can leverage the full scalability benefits of not relying on server/instance memory to manage session state. This approach allows a service such as Elastic Beanstalk to freely create and tear down app-server instances without affecting the user at all. Using sticky sessions does not allow this.

Some possible solutions I have considered include:

  1. Serializing/Deserializing "state" of user object user to store in client scope and "reinitializing" user on each page load
  2. Serializing/Deserializing "state" of user object user to store in NoSQL db and "reinitializing" user on each page load
Brian FitzGerald
  • 3,041
  • 3
  • 28
  • 38
  • If you are attempting to use ColdFusion on Elastic Beanstalk then read this bug post - [AWS Elastic Beanstalk rejects ColdFusion WARs](https://bugbase.adobe.com/index.cfm?event=bug&id=3365388) and related post here - http://stackoverflow.com/q/12217424/1636917 – Miguel-F Mar 02 '16 at 20:01
  • Interesting. I am attempting to run a docker container in production (yes, on Elastic Beanstalk), so if all the promises are true, as long as the docker daemon runs on the EC2 instance (which it does), the lucee app living inside the docker container should also run. Definitely working through some hurdles, but fingers crossed. – Brian FitzGerald Mar 02 '16 at 20:04
  • Lucee (Railo) does not have the issue from that bug, it relates to Adobe CF only I think. – Miguel-F Mar 02 '16 at 20:05

1 Answers1

4

If you do not/cannot use "sticky sessions" then another option is to implement session replication. This literally copies the session stored in memory to each node in the cluster. And, yes, there is overhead in doing this.

From the docs:

To implement session failover for the server instances in a cluster, enable session replication for each server instance. Session replication coordinates session information in real time among the server instances in a cluster. Enabling session replication lets Tomcat automatically route a request to a running server if the current server is unavailable.

Note: When a cluster uses session replication, session data is copied to other servers in the cluster each time it is modified. This can degrade performance if you store a significant amount of information in session scope. If you plan to store a significant amount of information in session scope, consider storing this information in client variables saved in a database.

From - Enabling clustering for load balancing and failover

Another caveat that is mentioned further down that page:

If you are using session replication, go to the Memory Variables page and enable J2EE sessions. Enable J2EE sessions for all server instances in the cluster. If J2EE sessions are not enabled in the ColdFusion Administrator, session replication does not function properly.CFC serialization lets you use J2EE session replication in a cluster and have access to the CFCs in session data across all instances in the cluster. Session replication also ensures that that Session scope variables are replicated across the cluster. However, session replication does not support replication of arrays in Session scope CFCs or variables.You can also preserve and access data in a CFC in the case of session failover. ColdFusion structures stored inside the session scope are available in the session scope, even after failover. For example, if you are running multiple ColdFusion instances to balance server load, you can store useful data, including CFCs, inside the session so that you can access the data across all the pages that are served in that session.

And also check this answer to the same question a while back (notice that there was a bug in earlier versions of ColdFusion 10 that did not allow session replication to work) - https://serverfault.com/a/602373/135433

Community
  • 1
  • 1
Miguel-F
  • 13,450
  • 6
  • 38
  • 63
  • Thank you for your response Miguel! I would rather make things simpler, rather than more complex though, so let's say I am willing to modify my application to make it stateless. What is the best way to store complex objects in a stateless environment? Serializing and deserializing a cfc state somehow and storing that in a db as json? "Repopulating" that user on each request? Something else? – Brian FitzGerald Mar 01 '16 at 16:42
  • I typically just use sticky sessions in our load balanced environments (to keep things simple). So not sure I can be of much help with your question. But my initial thought is that if your application is truly stateless then why would you need to _share_ anything between them? – Miguel-F Mar 01 '16 at 16:49
  • Thanks Miguel. I may just go with sticky sessions for a while, but at the end of the day, what must be stored is the session data, only that in order to make the app "stateless" it should be stored in such a way that it's not dependent on the server-memory of the server-instance on which it is running. This is where I've seen the client scope often used... the problem being that the client can't store complex data without some hackery. Just looking for ideas really. – Brian FitzGerald Mar 01 '16 at 17:11