Re: [OpenBD] Best method for session management

['Alan Holden' via Open BlueDragon]

Put another way, consider the basic reason(s) WHY you're going to apply more than one machine to an application: * You want the next one available when the present one is full of sessions, or * You want another one to take over in the event the present one fails, or * Some combination of both reasons, that you're still thinking over. When you use sticky sessions, you can easily handle the first reason. Each server stays with the person, start to finish. More persons, more servers. The balancing device assumes a perfect world scenario. But that solution doesn't help as much for the second reason. Some quantity of your users are going to be disrupted when the server (they are "stuck to") stops responding. If the device does swap them to a fresh machine, they'll get fresh sessions there, and probably flummoxed as well. That inconvenience is probably worse than the extra second it might take to get session data via the mongo/MemCache option, in which they continue without interruption from one machine to the next. There's no correct solution for everybody. It all depends on WHY: the priorities of your business methods I mentioned above. The nice part is that your business is doing well - if you actually have problems like this on the horizon. Al On 5/18/2015 11:04 AM, Jason King wrote: I figure with sticky sessions, scaling the front end is as simple as deploying another instance of the front end server, and adding the server's IP to the load balancing pool. On Mon, May 18, 2015 at 1:02 PM, nitish pandey <nitishpan...@gmail.com> wrote: Agree that the moment you have a shared node the scaling propensity comparatively lesser. Once the basic app is done with sticky session, maybe an appliance can be dedicated to continually backup the sessions. So when in a crash of a VM the sessions is restored. But that would be required if you are doing financial trading stuff. np On 18-May-2015 8:15 pm, "Jason King" <jasonalle...@gmail.com> wrote: Hi Alan,  My gut is saying performance would be better with sticky sessions because with this setup, session variables remain in the application servers direct memory.  All I need to setup is a simple load balancing pool with sticky sessions, and as long as the web/application server remains healthy, the user should have a good experience. Worst case scenario the server fails and they are pushed to a new server and they have to login again.  With using a shared session server (mongo/MemCache), it seems that any work the application servers do would rely on the shared session server's performance. And then I also need to account for scaling this deployment as well. As I add more application servers, the shared session server needs to scale as well.  It seems performance and scalability is easier to manage with a 'sticky session' configuration.  Thoughts?  On Sat, May 16, 2015 at 11:26 AM, Alan Williamson <a...@aw20.co.uk> wrote: It is a good question.   Bottom line - if you are don't want to use sticky sessions and want any server to pick up the request, then you need to look at something that is accessible by everyone, therefore Mongo/Memcached.   if you are happy with sticky sessions then don't create an additional server.   ------ Original Message ------ From: "Jason King" <jasonalle...@gmail.com> To: "Open BlueDragon" <openbd@googlegroups.com> Sent: 15-May-15 17:48:51 Subject: Re: [OpenBD] Best method for session management   I found this: http://openbd.org/manual/?/app_application_cfc "OpenBD makes it easy to make your applications run across multiple servers seemlessly without you have to worry about the logistics of moving the session scope around. You have the choice of using the following storage engines: Default in memory J2EE Session Management Memcached/CouchBase servers (this.sessionstorage = 'memcached://10.0.0.1:11211';) MongoDB servers (this.sessionstorage = 'mongo://10.0.0.1:27017';) Memcached/CouchBase Configuration You can easily use a remote farm of Memcached (or CounchBase) servers by specifying the connection URI: memcached://server1:27017 server1:27017 MongoDB Configuration More efficient than Memcached is the MongoDB storage engine. Sessions are loaded and saved to remote MongoDB servers (configured in a replic or sharded set). Sessions that have not changed, are efficiently handled as to not incurr the overhead of always moving data around. With the MongoDB connection URI, you can specify the Mongo database to use, though it defaults to 'openbd' with the collection 'sessions'. " I'm wondering.. should I just setup a MongoDB virtual machine for this and use it for session storage?  On Fri, May 15, 2015 at 3:48 PM, Jason Allen <jasonalle...@gmail.com> wrote: It's been a while since I've thought about this basic component of running a webapp, but I want to revisit it.  I'm building an app on CentOS7 with Tomcat as my webapp server. It works great.  That said, considering the app is a straighforward app with standard login mechanisms, what is the best way to manage user sessions? I plan on deploying multiple vServers of the app. I'll start with 3 vm's running the same app. I have a load balancer that will use sticky sessions to map users to one particular webserver as long as that webserver is healthy.  How should I manage cookies and sessions? Should I create a cookie in the user's browser that links it to a specific webserver, or should I create a database table and store cookies in there, assuming that in doing so, the users aren't locked in to any one specific web server.  I'm going to continue investigating this via google and searching, but if anybody has any input it would be greatly appreciated.  -Jason -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.