Continuation State Issues
Sunday, August 31, 2003
Avi's comments
Avi Bryant posted a comment on the continuation state issue in his blog:"This objection comes up a lot, but I've never been able to see it as a very big deal. Yes, session affinity - making sure the same user always gets redirected to the same server - is an absolute must, but that's true for most kinds of session state. So the only real problem is what to do when a server goes down. Frankly, I bet that for 99% of the applications out there, having one session in every 10,000 have to be restarted because of a server crash is going to cause so little grumbling as to be unnoticeable - and one in 10,000 would be a pretty unreliable server. The other 1% have to explicitly checkpoint onto shared storage at critical points. In languages where you can't easily marshal the dynamic state of a program, this might be a pain, but in Smalltalk it amounts to one line of code - just ask the VM to save the image.Maintaining state across web sessions has long been an issue that web application designers have struggled with. Continuation based web servers would seem to provide a convenient mechanism for maintaining state across requests. I obviously agree with Avi's comments, but what do the naysayers think about this? Are there things that we aren't seeing and should be taking into consideration?
But maybe I'm not taking this problem seriously enough. Is there some world of highly unreliable servers and extremely valuable session state (as opposed to domain state which is presumably kept in a database anyway) that I'm oblivious to?"
Are Continuation-based web servers workable?
I got an email in response to my posting about Continuation based web servers that questioned whether they are a workable approach (at least for large web server applications). The email and my reply are below.
> A point often missed is that in typical commercialI'd be interested in hearing from others on their thoughts about this topic as well. In particular, how often is #2 required and what alternative approaches can be used.
> web environments, a 'web farm' is used rather than
> a single web server. At this point the 'Continuation
> based web servers' crowd now leave the
> distributed Continuations 'as an exercise ...'
Whether you use continuations or some other mechanism for maintaining state, you still need to do one of a number of things to maintain a secure session state. Two things that come to mind are:
1. Make certain that the user is always directed to the same server (via cookies, hidden fields, url rewriting) for the duration of that users login session.
2. Be able to persist the continuations.
You might take the first approach if the likelihood of a server going down is not very high or if the cost of having a user restart their session is low. If not, you would need to use the latter approach.
