views:

95

answers:

3

I have an asp.net application running in a server farm. So In-proc sessions are out. There's no state server. There's a sql server database (can't be used for state server). There's no forcing same web server serving capabilities so no guarantee which web server will serve next page.

I need to save a block of data (big object state) between pages. I don't want to use viewstate because data could be large and don't want it to go across the wire. I could use the database to save the data and use the record id across the wire in a viewstate and retrieve the data for the next page.

Are there better solutions?

+4  A: 

I could use the database to save the data and use the record id across the wire in a viewstate and retrieve the data for the next page.

You've eliminated every other option.

Spencer Ruport
+1  A: 

Well, I guess you've ruled out most options already. And assuming you cannot install other services, two other possibilities come to mind:

  1. Use a writable file share to store the data.
  2. Allow the individual web servers to communicate with each other. For instance, make the machine's IP or name part of the generated unique identifier; that way, if you reach a different server on postback, that server can call the original server for its data. Mind you: if one server goes down (or the ASP.NET process is recycled), all it's data is lost.* That shouldn't happen that often, I hope, regardless of this subject.

As in the SQL Server version, don't forget to clean up your data somehow; option 1 is pretty similar to SQL Server in that regard, but in case of SQL Server it could simply be a centralized cleanup job, in the file share case the question becomes: which server is the center?

*) You could, of course, try to spawn a secondary process from ASP.NET. The problem here becomes: what if that process has problems? It's not manageable for your sysadmins by default, unless you make it manageable.

Ruben
You're answering his question, but I hope it's clear to everyone these are horrible hack jobs. In fact, both items you suggested are simply crappy alternatives to the more common approaches. (Common file share => common data store => database store)
Spencer Ruport
Sure, but the guy wants options, and the non-crappy ones are not possible. However, I don't totally agree on common file share => common data store => database store. A relational database is not an anonymous BLOB-store. That's just as crappy as a file share. You should preferably *model* the data you're going to store, but from the question I gathered that suggestion's a little too late.
Ruben
Yes.. when the standard procedures are not available, one will resort to hacks. This doesn't mean hacks don't work. If ones takes enough precautions and defensive programming, they should be good enough.
Tony_Henrich
A: 

I'm not sure if I read right, but can you not use the database to store the asp.net session?

<sessionState
      mode="SQLServer"
      sqlConnectionString="somedb"
      cookieless="AutoDetect"
      timeout="20"
    />

You could also use some sort of distributed caching solution like memcached(http://www.danga.com/memcached/ and that could persist the data between postbacks.

Nick