Which session state is best to use

I am running with Sql Server and am curious if I should use in-process,
State Server, or SQL Server.

By default, I assume I am using in-process (I could be wrong here, however).
I am not actually defining it in my web.config.

I was thinking about moving to Sql Server mode, but am not sure what I would
gain or lose by changing.

One thing I was curious about, was if this would make it easier to figure
out who was using our system at any particular time (their sessions haven't
timed out yet).

Thanks,

Tom

tshad

There is no right answer for this, rather there are recommendations based on
your requirements. If you move to sql server session, you incur a
performance penalty but you also get to use session in webfarms and gardens.
In proc is the default mode by the way, as defined in the web config file.

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________


"tshad" <> wrote in message
news:...
>I am running with Sql Server and am curious if I should use in-process,
>State Server, or SQL Server.
>
> By default, I assume I am using in-process (I could be wrong here,
> however). I am not actually defining it in my web.config.
>
> I was thinking about moving to Sql Server mode, but am not sure what I
> would gain or lose by changing.
>
> One thing I was curious about, was if this would make it easier to figure
> out who was using our system at any particular time (their sessions
> haven't timed out yet).
>
> Thanks,
>
> Tom
>

Alvin Bruney [ASP.NET MVP]

Two things:

1) I'd suggest not using Session state at all if you can avoid it. This isn't
always possible, but you avoid some types of problems later on if you can.

2) If you are going to use it, then don't accept the default of InProc. The
primary reason is that your worker process and/or AppDomain (essentially
the two different hosting environments) recycle very often (more than you'd
think) and as a side effect your in memory state (read: InProc Session State)
will be lost. It's odd, IMO, that this is even an option in ASP.NET. So,
in short: never use InProc Session State and configure it to be out of process.

-Brock
http://staff.develop.com/ballen



> I am running with Sql Server and am curious if I should use
> in-process, State Server, or SQL Server.
>
> By default, I assume I am using in-process (I could be wrong here,
> however). I am not actually defining it in my web.config.
>
> I was thinking about moving to Sql Server mode, but am not sure what I
> would gain or lose by changing.
>
> One thing I was curious about, was if this would make it easier to
> figure out who was using our system at any particular time (their
> sessions haven't timed out yet).
>
> Thanks,
>
> Tom
>

Brock Allen

>It's odd, IMO, that this is even an option in ASP.NET. So, in short: never
>use InProc Session State and configure it to be out of process.
It's not odd. Recycling application promotes greater stability and immunity
towards errant processes leaking memory among other things. There is a
reason why inProc is the default mode, because it works best for a large
number of applications. If you recommend switching modes, you should have a
sound reason and thoroughly understand the consequences such as performance
degradation occuring when session passes thru the
serialization/deserialization layer.

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________


"Brock Allen" <_hate_spam_too> wrote in message
news:.. .
> Two things:
>
> 1) I'd suggest not using Session state at all if you can avoid it. This
> isn't always possible, but you avoid some types of problems later on if
> you can.
>
> 2) If you are going to use it, then don't accept the default of InProc.
> The primary reason is that your worker process and/or AppDomain
> (essentially the two different hosting environments) recycle very often
> (more than you'd think) and as a side effect your in memory state (read:
> InProc Session State) will be lost. It's odd, IMO, that this is even an
> option in ASP.NET. So, in short: never use InProc Session State and
> configure it to be out of process.
>
> -Brock
> http://staff.develop.com/ballen
>
>
>
>> I am running with Sql Server and am curious if I should use
>> in-process, State Server, or SQL Server.
>>
>> By default, I assume I am using in-process (I could be wrong here,
>> however). I am not actually defining it in my web.config.
>>
>> I was thinking about moving to Sql Server mode, but am not sure what I
>> would gain or lose by changing.
>>
>> One thing I was curious about, was if this would make it easier to
>> figure out who was using our system at any particular time (their
>> sessions haven't timed out yet).
>>
>> Thanks,
>>
>> Tom
>>
>
>
>

Alvin Bruney [ASP.NET MVP]

> It's not odd. Recycling application promotes greater stability and
> immunity towards errant processes leaking memory among other things.

Yes, of course. And that's why this is a welcome feature.

> There is a reason why inProc is the default mode, because it works
> best for a large number of applications. If you recommend switching
> modes, you should have a sound reason and thoroughly understand the
> consequences such as performance degradation occuring when session
> passes thru the serialization/deserialization layer.

I think the vast majority people don't "thoroughly understand the consequences"
of leaving session state at InProc. The AppDomain/worker process recycle
a heck of a lot more than people realize and if your app relies upon session
state, then the robustness of keeping the data out of proc is the price to
be paid. As I said in my earlier post, I recommend avoiding session state
all together if possible.

But the reality is that most performance problems come from bad SQL and inefficient
trips to the database. Of course there is overhead to the StateServer Service
but if you're using InProc session state, then you'd only be making a cross
process call, as the StateServer Service would/should be configured on the
same machine. The overhead of the local access to the StateServer is dwarfed
by the network latency of hitting the DB.

As with anything, understand what you're doing. As far as performance, correctness
comes first. Don't optimize until you've profiled.

-Brock
DevelopMentor
http://staff.develop.com/ballen

Brock Allen