Enterprise Session Storage

Published Monday, March 1, 2004 12:38 PM

Session storage within .Net is a huge improvement over the classic ASP type methods. The inbuilt support for Inproc, StateServer and SqlServer is great. One thing that has plagued me for sometime though is that I have been unable to use it in almost every enterprise application I have written (bar one).

Inproc is not scalable (ie. can't make it work in a web farm unless you reduce scalability by using something like sticky sessions and ensuring a user is always redirected to the same box), and SqlServer requires direct access to the database from the web server, which isn't appropriate for me as I work on 3 tier apps where the web server has an application server in between. StateServer can be used in this instance but it introduces a single point of failure and also the problem of where to store the session data. You can dedicate a separate machine to the task but this is hard to justify in terms of hardware purchasing. You can store it on “one” app server, but this affects this app servers memory usage and processing abaility (depending on how often its used).

One of the things that new devs in our organisation get excited about is the new session management features, until we inform them that they wont be able to use it on project <x> due to the 3 tier nature (StateServer not being used for reasons above).

It is with this in mind that I have been working feverishly on a (get ready for a stupid name) “MultiHop Session” library for our next project, which enables you to use syntax like :-

Session[”variable name”] = objSomeThing;

objSomeThing = Session[”variable name”];

but which gets cascaded through the app server to the Sql database that is connected to the application server. So we can cluster the database and also have the potential of using any app server to cascade the session storage and retrieval requests. It uses either remoting or web services, operates over port 80, and is currently limited to Http. It does not employ a separate service, and hooks into the Session_Start, Session_End events (sort of). It is working currently but only in a rudimentary fashion and requires some work but is well on its way. You just include the library, set some config items, make your Global object inherit from MHWebApplication instead of the default, and you are away.

One thing I have found is the “weirdness” that is the Session_Start and End events. If you reflect over these, you'll find they aren't really events (in the .Net sense) but just methods that get called at (supposedly) start and end of each session. It seems that these events aren't particularly reliable though and found that they sometimes operate/fire a bit differently on some systems. Has anyone experienced this before? BTW, this library I am developing relies on the Inproc session model being enabled so that these “events” are fired.

Also, if there is any interest in the library I am working on, I'll probably throw it out in the community with complete source code but its not ready yet and I'll go by the interest in it, if any.

(I'll complain about the lack of the extensibility of the current - 1.0/1.1 session model in another post...;-) )

by Glav

Comments

# Jason Mauss said on Sunday, February 29, 2004 10:16 PM

This sounds similar to something I was looking into doing for a classic ASP application. What ended up happening was we'd just put a "session GUID" into a cookie, which matched a GUID in the database for the user. Whenever we needed types of "session" info - usually a user id or something like that - we would get it from the database using the GUID value from their cookie. It just seems like a better solution than using the "Session" since storing values in the Session object doesn't scale very well anyway.

# Brian Reischl said on Thursday, May 27, 2004 5:47 PM

Hey Glav,
OK, second post to your blog (it beats working I guess 8-) )

Your comments about InProc and Stateserver are definitely on, in fact I think MS points out those weaknesses in a few places. But I'm a little confused as to the problem you have with SQLServer persistence, and how your solution would help.

It seems to me that if you're using Session from your "webserver" then it must be running logic of some sort. In that case is it really a pure 3-tier app anyway? You've already "polluted" that tier to some extent, so using Session directly would seem like a minor concession to make.

And even if you do pass the session data through the middle-tier, have you really accomplished anything? Just proxying through the middle tier doesn't have any real effect on the architecture, from a coupling perspective. The webserver is still getting raw session data from the backend, just through a proxy...

The one reason I could see this making sense is if you had firewalls between your webservers and session state DB. But even then, it seems like it would be simpler and (probably...) no less secure to just punch a hole through the firewall. Unless you work with some serious firewall Nazis :)

Hope this doesn't seem too confrontational... it's just that I don't get it :)

BKR

# Paul Glavich said on Thursday, May 27, 2004 7:32 PM

Hi again Brian,
Great to read your comments again and no, not confrontational at all. I enjoy the feedback. Re: your concerns on session state I mentioned, again you are pretty much spot on.
The problem I was trying to address here is that I dont get visibility on every project in our org, so I dont always get input on how things are done. One of the mandates of one of our clients is to use 3 physically separated tiers. so this "proxy" use of session is just a tool to enable session usage semantics, while still maintaining the 3 tier scenario.
Its reasonably specific in what its trying to address and to be honest, I dont personally use it a lot because when I design systems, I take a very different approach. Having said that, it has been useful to use for some people in the org. Performance and design wise though, like you have stated, probably not the best choice, but it did help to get things done in certain situations, and the end result worked, so its all good ;-)

One of the side benefits was trying to dig deep and extend the existing session system. I got to find out how extensibe (or not) it is, how best to try and extend it, etc. so its was a good familiarity and leaning excercise too, which has helped in other areas.

I do appreciate your comments and feedback though Brian...keep em coming.

# Brian Reischl said on Friday, May 28, 2004 4:50 PM

Hey Paul,
Guess it makes sense then. I think we've all been in those positions where there's no really "good" solution, and you just have to grit your teeth and hack something.

So, how extensible (or not) is the session system? 8-) Do you have any docs or guides you could post links for? I don't have any particular use in mind, but it's always good to know what's possible, just in case...

BKR

# Paul Glavich said on Saturday, May 29, 2004 12:41 AM

Well not very extensible at all unfortunately. Certainly not without some tricks and hacks, all of which are not particularly elegant. Of particular note is the fact that the "Session events" are not really events at all, but just methods that the framework looks for and calls, so trying to hook into them as if they were events does not work. A little "reflection" over these things verifies this.
I am happy to forward on some code I have, which is the partially complete version. This is the code that was used a base from which the organisational specific changes were made to be used. In its current form, it does work, but there is still plenty missing. It only uses remoting (although has support for other methods), and hasn't been fully tested as is. To get the semantics I was after, I had to extend the System.Web.HttpApplication class (and use that in the Global.asax) as well as the System.Web.UI.Page class, and also use that in place of the standard classes.
If you are interested, just leave your email address and I'll send it through.
The new extensibility model in whidbey should make this type of thing a hell of a lot easier, and nicer to implement.

Leave a Comment

(required) 
(required) 
(optional)
(required) 

This Blog

Syndication