Reason we were doing the session to wddx to client var, and reverse, was we are in a multi-server environment and not using the jrun session replication from server to server because of jrun's poor performance doing session replication across a cluster.
Our load balancing scheme was (at the time) non-sticky. So a user could jump from server to server, so we needed a more reliable way of transporting the sessions from one server to another, since each user request could wind up at another server. So at the end of a request, we wddx the session structure to a client variable (and into the db), on the beginning of each request, we took the client var, reversed the wddx, and set all the session variables. Thus a lot of overhead. We wound up changing the load balancing to sticky sessions, so first request from a user goes to one server, and all subsequent request go to that same server unless it goes down. At that point it wasn't necessary to "replicate" the sessions with the wddx methodology. If a server dies, we are ok with a session lost and having the user potentially having to login again. This is a user experience vs. performance trade off we are willing to accept. >From your description it sounds like you just want a user to go from http, to https, login, and jump to the original requested page. Session vars would be the way to handle tracking that requested page through the login process and then redirecting to the correct destination. Once the user is authenticated in the ssl portion of the site, subsequent secure request (from non ssl) would bypass the login and go directly to the requested page. Basically you would have 2 sessions, one http and one https, but after logging in the transition back and forth would be seamless, unless the https session times out from inactivity and the user has to log back in. This is all based on a single server concept. If you are trying to maintain the session across server instances then you would need a mechanism to replicate the user sessions across each instance in you cluster. Like we did with the session to wddx to client var and back to session, or Jrun in memory server to server session replication. Hope this helps, I think this thread got into two different areas; although somewhat related. Byron Mann Lead Engineer and Architect Hostmysite.com On May 17, 2012 3:16 PM, "Nick Gleason" <[email protected]> wrote: > > Hi Byron (and others), > Quick follow up re: eliminating client variables (and wddx, etc.). Are you > saying that you are able to maintain login persistence using sessions with > the whole site in https so that you don't have to worry about logins being > dropped with sessions (which is probably what we will do)? Or did you move > to some other solution for login persistence? > Another, related, example would be maintaining a url throughout a login. > For instance, if you are on a site and click on a link to a password > protected, you will be re-directed to the login screen. Once you login, we > would like you to be directed automatically to the page. Sessions would be > a handy way to do that. But, if we wanted to maintain the option to not > have the whole site in https, then using sessions for this functionality > would seemingly have the risk of sessions being dumped when you move into > https and you would not be automatically redirected to the target page > after login. So, again, I'd be interested in knowing alternate ways to > handle that kind of scenario. (We have a way now but it may not be the most > elegant). > Thanks again, > Nick > > ---------------------------------------- > Return-Path: <[email protected]> > Received: from mail.houseoffusion.com [64.118.74.225] by > mail67.safesecureweb.com with SMTP; > Wed, 16 May 2012 01:37:33 -0400 > To: cf-talk <[email protected]> > Message-ID: > <CAOSLZN=gUmOtmkyYOShWsPjrcoQKqgo6o7=fj0uASANHxd=8...@mail.gmail.com> > Subject: Re: best practice on session variable persistence and ssl? > References: > <caclzgdmagqbd5e97e-99judpnaguzxh0abd41uyiiuuhvye...@mail.gmail.com> > Date: Wed, 16 May 2012 01:37:16 -0400 > Precedence: bulk > Reply-To: [email protected] > From: Byron Mann <[email protected]> > MIME-Version: 1.0 > Content-Type: text/plain; charset="ISO-8859-1" > Content-Transfer-Encoding: 7bit > X-Rcpt-To: <[email protected]> > X-SmarterMail-Spam: SpamAssassin 0 [raw: 0], SPF_None, DK_None > X-SmarterMail-TotalSpamWeight: 0 > > I hear ya, since we eliminated the client variables all together and that > whole wddx thing, our (internal) cf instances only go down during OS > patches. Can't remember the last time I had to restart the service > itself. > > Should also mention we are using jetty which has seemed to uptick > performance all around. > > Now shared is another ball of wax. > > Byron Mann > Lead Engineer and Architect > Hostmysite.com > On May 16, 2012 1:30 AM, "Andrew Scott" wrote: > > > > > Funny you should mention high session time outs. > > > > I was given a task by a friend to look at, on something that I did many > > years ago. Since then they had another developer come in make some > changes > > and the server fell over about 5 times a day, when I looked at it, the > > session was set to 2 days, I was like WTF... > > > > Change it back to what I had set it at 6 years ago, and 8 months later > it > > hasn't fallen over once. > > > > -- > > Regards, > > Andrew Scott > > WebSite: http://www.andyscott.id.au/ > > Google+: http://plus.google.com/108193156965451149543 > > > > On Wed, May 16, 2012 at 3:12 PM, Byron Mann wrote: > > > > > > > > Note on the wddx, we were doing the same thing. We put a to client > scope > > in > > > the onrequestend.cfm and to session in the application.cfm/c > > > > > > This was all good until we started adding a lot of ajax calls and > greatly > > > increased the total numbed of http requests. We had all kinds of > latency > > > issues and even client db corruption from the number and size (we had > > > rather large session structures) of write operations. This at one > point > > was > > > adding about 1.5 secs per request. > > > > > > We first moved to json serialization which seemed faster and smaller > in > > > size than wddx. > > > > > > Though, eventually we moved away from client vars all together and are > > just > > > using session variables for all apps on our internal cluster. > > > > > > I doubt I'll every use client vars again, even in a cluster, and I've > > also > > > learned to keep sessions as small as possible. One of our main issues > > with > > > shared cf hosting are apps that have large sessions which hog > resources. > > > Came across a customer today with 100 sessions totalling about 45 MB, > and > > > that's just one example. High session timeouts are another factor in > > > performance as well. Often seen customers requesting us to up the > maximum > > > to days, no so good :-) > > > > > > Byron Mann > > > Lead Engineer and Architect > > > Hostmysite.com > > > On May 15, 2012 2:44 PM, "Nick Gleason" wrote: > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:351243 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
