No we're not. We use InProc for development which I believe is the way to go, but we also use InProc for the state management of our production apps too (cringe) but I have told the powers that's a bad idea since it is so volatile ... however, nobody is going to listen to me. :-)

Regarding the general issue there are pros and cons as always. There's actuallly a lot of information available in articles on this subject but the gist is basically:

1) InProc is the fastest since it's in proc. :-) But it's also the most volatile since if anything touches the web folders it can trigger IIS to "restart" the web application which unloads all the state data, so the guy who just spent 20 minutes filling his shopping cart just got it unloaded for no extra fee. :-) I believe some virus scanners have been known to trip the switch that causes IIS to reload the app.

2) State Server is quite good and is made for this task. It's fast also since, I believe, for the most part it holds state data in memory. But it is isolated from IIS and, AFAIK, could even be on a different server. There's some overhaed of course marshalling the state data back and forth to IIS but I beleive if it's set up properly it's not a lot slower than InProc. It requires objects held in state to be serializable.

3) Finally there's SQL Server which would be the most fault tolerant the data is stored in a DB, and I would probably push for using it if bullet proof state management was needed. But it is arguably also the slowest of the three. It also requires serializable objects.

There's a lot more info out there on this stuff but that's the 2 cent version.

Bill

>Hey Bill,
>
>Just curious ... are you storing your Sessions in SQL Server?
>
>~~Bonnie
>
>
>
>>Hey Bonnie,
>>
>>No prob. Your answer was correct. I use more than one method for maintaining state but Session definitely the most. I just wanted to provide some additional info.
>>
>>Bill
>>
>>>Thanks for the correct answer, Bill. As I said, I wasn't 100% sure either way.
>>>
>>>~~Bonnie
>>>
>>>
>>>
>>>>Hi Chad,
>>>>
>>>>Alwaus good to just go ahead and add the [Serializable] attribute to classes that will be stored in Session. If you wind up using State Server or SQL Server to manage state, the objects have to serializable.
>>>>
>>>>Bill
>>>>
>>>>>Bonnie,
>>>>>
>>>>>Can any object be stored to a Session object and retrieved back as that object:
>>>>>

>>>>>Session["MyObject"] = myCustomObject;
>>>>>

>>>>>

>>>>>CustomObject myCustomObject = (CustomObject)Session["MyObject"];
>>>>>

>>>>>Will I have to write special serialization/decoding code to make that happen?
>>>>>
>>>>>TIA,
>>>>>Chad
>>>>>
>>>>>>Hi Chad,
>>>>>>
>>>>>>I haven't done much with Web apps lately, but when I was messing around with them a couple years back, I determined that the best way to persist data was with Session objects.
>>>>>>
>>>>>>~~Bonnie