Agreed.
Back in the day we did actually "need" sessions to hold across servers, but we went with the client-vars-in-the-DB to do it. Don't know if AOL still does this, but back in 2004 when many end users (B2C) were still using AOL as their ISP, AOL had a habit of changing a user's IP every 3 or 4 page requests ... which played hell with load balanced e-commerce sites, since the LB treated a new IP as a new session which may or may not get the same server assignment. By linking the "session" from the browser to the application (via client vars) rather than from the browser to the server (via session vars) we were able to smoothly pass "sessions" within an application from one server to another without issue. Barring that, though, just for a typical web experience, it's simply not needed. If you could guarantee that users won't have their IPs changed in mid-visit, it would also not be needed. ---------------------------------------- From: "Sean Corfield" <seancorfi...@gmail.com> Sent: Tuesday, January 25, 2011 12:48 PM To: "cf-talk" <cf-talk@houseoffusion.com> Subject: Re: Clustering ColdFusion - some "black holes" I hope Mike Brunt is still on this list and will jump in on this because he has a lot of experience with clustering JRun and has a lot to say about session replication and other options (basically he agrees with Dave :) My experience with session replication on JRun was that replication could lag and you could get failover to occur without session data being fully replicated so you'd lose data anyway. This is true of most JEE containers (although JRun's session replication does seem a little less robust than some of the others). You may also generate a huge amount of internal network traffic as all session variable updates are replicated to other servers in the cluster. If you grow the cluster, you increase the network traffic as each server has to replicate to every other server - which is why most folks who even go down this path tend to partition the cluster into small, replicating groups with the load balancer set to failover only within a group (unless the whole group goes offline, when it fails over to a new group and you lose sessions). In general, very, very sites have such critical session data that they need to replicate. Everyone seems to think they need it but the reality is that failover is (should be!) rare enough that the number of end users adversely affected on most sites is minuscule and, frankly, if your servers are failing over regularly, you have bigger problems than session loss. One thing that a cluster with failover does buy you is the ability to do rolling deployments across the cluster with zero downtime (depending on how you manage database updates, of course), but even then there are other options, such as using a load balancer that supports session draining on sticky sessions etc (that was how we did it at macromedia.com / adobe.com). Sean On Tue, Jan 25, 2011 at 6:10 AM, Dave Watts <dwa...@figleaf.com> wrote: > Is there a specific requirement for session replication? Because you > might get generally better results if you just use sticky sessions. > That buys you load balancing, but not complete failover - but it may > be enough, if your failure rate is acceptably low. > > I've set up session replication for a couple of clients, and the whole > thing just seemed a bit fragile to me. I'd prefer to use a database > for session management in this case, I think - which might involve > using Client variables instead of Session variables, or might involve > custom code to synchronize Session variables with a database. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:341182 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
