Application State in Web Farm Scenario RRS feed

  • Question

  • I have a web farm scenario wherein I need to store data say a dataset into the application cache/state. My backend is not SQL Server.

    The challenge is that, I know application state is ASP.Net Worker process specific. So whenever the process gets recycled so would the data. In short Application state is not durable.

    Now in a Web farm or a Web garden scenario there is no way I can access the Application variable from other server because of the above behavior.

    Is there any way to address this requirement.

    Would appreciate some thoughts on the same.

    Wednesday, May 3, 2006 6:46 AM

All replies

  • One option is to use SQL server to store the data (as well as session state - the are several KB articles that talk about it - here is one).

     There are several options to scale out SQL server. Roger Wolter presents them nicely in the following article

    Your other option is to use some distributed cache product

    Wednesday, May 3, 2006 8:04 AM
  • Hi Sai,

    > I have a web farm scenario wherein I need to store data say a dataset into
    > the application cache/state. My backend is not SQL Server.

    What is your "back end"? Is there a shared database?

    > The challenge is that, I know application state is ASP.Net Worker process
    > specific. So whenever the process gets recycled so would the data. In
    > short Application state is not durable.

    Right. To avoid this, you must either store the information in a shared data store (such as a database), or cluster the data.

    Clustering the data is simple using a product like Coherence for .NET. See



    Thursday, January 11, 2007 12:51 PM
  • While we always encourage using SQL Server for your session state store, you can also implement your own state store on the database of your choice.  Here's an article on how to to it that contains a link to a sample.


    Friday, January 12, 2007 6:35 PM
  • Hi Roger,

    While storing session state in a database solves the problem of not being able to share session data across the farm, it is far from perfect. Performance-wise, executing multiple stored procedures per each HTTP request, serializing and deserializing session data and storing it in BLOBs is definitely not the fastest of operations and adds significant overhead to each HTTP request (and there is a lot of requests in a typical ASP.NET application due to the underlying postback-based architecture).

    When we get to scalability, it's no secret that database (any database) will only scale out so much. In your article you pointed out that you can have an 8-way SQL Server configuration, but that requires read-only access to data. That's clearly unacceptable for session sharing, so we need to look at other options. Peer-to-peer topology also won't fly due to the fact that conflict resolution is not automatic. So, there really aren't many options for scaling out session state database.

    On the other hand, with a data grid product such as Tangosol Coherence, you can scale out pretty much linearly by simply adding more boxes to the grid. Coherence also guarantees that data within the grid will be, well, coherent -- no conflict resolution to deal with, whichever node in the grid you ask for a piece of data you will alway get current, up to date stuff. Then you consider the fact that you can scale Coherence grid to thousands of servers, and you can see why such a solution would both perform and scale much better than any database.

    Best of all, Coherence for .NET ships with a session store provider, so switching to a Coherence-backed session state store is as simple as changing session state provider in your Web.config:

    <sessionState mode="Custom" customProvider="CoherenceSessionProvider" timeout="20">
            <add name="CoherenceSessionProvider" type="Tangosol.Util.Web.CoherenceSessionStore, Coherence" cacheName="dist-session-cache"/>

    That's all there is to it -- no code changes are required and the requirements are exactly the same as for built-in out-of-proc session store providers: that stored objects are serializable. It's a simple, drop in replacement.

    As for the original question, which I belive was how to make application state shareable, there is unfortunately no extension point in ASP.NET that allows that. However, it is still possible -- you just need to shadow Application property of the Page class (unfortunately you cannot simply override it, as it is not virtual) and implement it to use Coherence data grid as a backing store. That's exactly the approach we are taking in Spring.NET to allow for pluggable ApplicationState and Cache stores within ASP.NET web apps.



    Sunday, January 14, 2007 2:07 AM
  • Cool, happy we could serve as a commercial opportunity for you.  Some of the smaller web sites like Amazon, Ebay, MySpace, and get by with databases for session state but they don't have to scale much past a few hundred million users.
    Sunday, January 14, 2007 5:32 AM
  • Hi Roger,

    Just to clarify, I am not Tangosol employee, do not own equity in Tangosol, and have no financial incentive whatsoever to tout Coherence as a possible solution for session state management. I *have* done contract work for Tangosol on a work-for-hire basis and I *do* use their product on my projects, and I *am* more than happy to recommend them to my customers who need services that Coherence provides. It truly is a remarkable product and I an very excited that it is finally available on a .NET platform as well, but that's the extent of my relationship with Tangosol -- I don't make a dime from their license revenue.

    Considering that this is architecture related forum, I was simply trying to point out that there are better alternatives for session state management (and many other things, btw) out there than databases. I am not saying that you cannot use database for the task, just that it's probably not the best tool for it. Databases are great for the storage of persistent data, but session state is anything but persistent. It is transient data that is best kept in memory as close to the web application as possible. Its lifetime is usually very short, from a few minutes to a few hours. If the session state needs to be persisted *between* the sessions, sure, there is nothing wrong with storing it in a database, but doing so for each HTTP request could be considered an overkill by some ;-)

    I am also not saying that you cannot have a large, high-traffic site that uses database as a session state store -- we all know there are many such sites out there, as you point out, so there is no reason for sarcasm. The question, however, is whether that's the optimal way to do it or not. Chosen session state management strategy *does* have an impact on the number of simultaneous requests each web server in a farm can process. If we can increase that number by using data grid rather than database for storage, that means that we will need less servers in a farm for the same number of simultaneous users. This can lead to significant hardware and software savings.

    Now, it is somewhat pointless to discuss all of this without providing some hard numbers that would support my theory. I will try to run some stress tests using both Coherence and SQL Server and will post results here. It might take a while as I'm extremely busy at the moment, but I'll try to do it as soon as possible.

    In the meantime, if you want to have technical discussion and show me why databases are a better option, please do so, but let's leave politics aside. After all, why is it considered product pushing when someone talks about the thirdy part product they are very much impressed with, and not when both MS employees and third parties talk about and recommend MS products?



    Sunday, January 14, 2007 3:10 PM
  • Hi Roger -

    I appreciate your skepticism, and in this industry it is no doubt well deserved. I would welcome the opportunity to explain a bit more about what we do if you have the time and interest. You can email me at first initial last name at company name dot com (I use spamarrest, so you'll get an initial bounce / challenge).

    We do not compete at all against Microsoft SQL Server, and we hope to do a very good job supporting our customers using .NET and other Windows technologies. I would be interested in your feedback, once you see what we do.

    FWIW - I have been directly involved with architecture discussions for two of the four sites that you mentioned. You might be surprised by how some of those sites work. It's a lot more complicated than "storing sessions in the database" ;-)


    Cameron Purdy
    Sunday, January 14, 2007 5:32 PM