Session_End and SqlServer Session Mode

[karahan celikel]

I realized that when SqlServer mode is used for session management
Session_End event is not fired in global.asax.
What can I do if I want to do something when a user's session end?

Thanks

[Alvin Bruney [MVP]]

well isn't that the whole point of using sqlserver mode? that you don't want
to be affected by session end events? the session end event you are hoping
to target is only supported in inproc mode when the session data is stored
in the asp.net worker process.

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"karahan celikel" <NO*******************@hotmail.com> wrote in message
news:eb**************@TK2MSFTNGP11.phx.gbl...

I realized that when SqlServer mode is used for session management
Session_End event is not fired in global.asax.
What can I do if I want to do something when a user's session end?

Thanks

[Yan-Hong Huang[MSFT]]

Hello Karahan,

Thanks for posting in the group.

I agree with Alvin that Session_End event is supported only in InProc mode.

Here is a quick summary of the major things you need to know about picking
asp.net session state mode:

Storage location
----------------
InProc - session kept as live objects in web server (aspnet_wp.exe)

StateServer - session serialized and stored in memory in a separate process
(aspnet_state.exe). State Server can run on another machine

SQLServer - session serialized and stored in SQL server

Performance
------------
InProc - Fastest, but the more session data, the more memory is consumed on
the web server, and that can affect performance.

StateServer - When storing data of basic types (e.g. string, integer, etc),
in one test environment it's 15% slower than InProc. However, the cost of
serialization/deserialization can affect performance if you're storing lots
of objects. Have to do performance testing for your own scenario.

SQLServer - When storing data of basic types (e.g. string, integer, etc),
in one test environment it's 25% slower than InProc. Same warning about
serialization as in StateServer.
Robustness
-----------
InProc - Session state will be lost if the worker process (aspnet_wp.exe)
recycles, or if the appdomain restarts. It's because session state is
stored in the memory space of an appdomain. Read doc on when such events
will happen.

StateServer - Solve the session state loss problem in InProc mode. Allows
a webfarm to store session on a central server. Single point of failure at
the State Server.

SQLServer - Similar to StateServer. Moreover, session state data can
survive a SQL server restart after you've followed instructions in KB
311029.

Caveats
--------
InProc - It won't work in web garden mode, because in that mode multiple
aspnet_wp.exe will be running on the same machine. Switch to StateServer
or SQLServer when using web garden. Also Session_End event is supported
only in InProc mode.

StateServer - In a web farm, make sure you have the same <machineKey> in
all your web servers. See KB 313091 on how to do it. Also, make sure your
objects are serializable. See KB 312112 for details.

SQLServer - If you specify integrated security in the connection string
(e.g. "trusted_connection=true", or "integrated security=sspi"), it won't
work if you also turn on impersonation in asp.net. Unfortunately, this bug
isn't reported in KB yet. (There is a QFE fix for it.) Also, make sure
your objects are serializable. See KB 312112 for details.

Does that answer your question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Karahan Celikel]

Thanks Alvin and Yan-Hong for your replies.

but isn't it weird that session_start is fired but not session_end?

"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
news:Qt**************@cpmsftngxa07.phx.gbl...

Hello Karahan,

Thanks for posting in the group.

I agree with Alvin that Session_End event is supported only in InProc mode.
Here is a quick summary of the major things you need to know about picking
asp.net session state mode:

Storage location
----------------
InProc - session kept as live objects in web server (aspnet_wp.exe)

StateServer - session serialized and stored in memory in a separate process (aspnet_state.exe). State Server can run on another machine

SQLServer - session serialized and stored in SQL server

Performance
------------
InProc - Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.

StateServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc. However, the cost of
serialization/deserialization can affect performance if you're storing lots of objects. Have to do performance testing for your own scenario.

SQLServer - When storing data of basic types (e.g. string, integer, etc),
in one test environment it's 25% slower than InProc. Same warning about
serialization as in StateServer.
Robustness
-----------
InProc - Session state will be lost if the worker process (aspnet_wp.exe)
recycles, or if the appdomain restarts. It's because session state is
stored in the memory space of an appdomain. Read doc on when such events
will happen.

StateServer - Solve the session state loss problem in InProc mode. Allows
a webfarm to store session on a central server. Single point of failure at the State Server.

SQLServer - Similar to StateServer. Moreover, session state data can
survive a SQL server restart after you've followed instructions in KB
311029.

Caveats
--------
InProc - It won't work in web garden mode, because in that mode multiple
aspnet_wp.exe will be running on the same machine. Switch to StateServer
or SQLServer when using web garden. Also Session_End event is supported
only in InProc mode.

StateServer - In a web farm, make sure you have the same <machineKey> in
all your web servers. See KB 313091 on how to do it. Also, make sure your objects are serializable. See KB 312112 for details.

SQLServer - If you specify integrated security in the connection string
(e.g. "trusted_connection=true", or "integrated security=sspi"), it won't
work if you also turn on impersonation in asp.net. Unfortunately, this bug isn't reported in KB yet. (There is a QFE fix for it.) Also, make sure
your objects are serializable. See KB 312112 for details.

Does that answer your question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Patrice Scribe]

What do you want to do ?

Sometimes it's possible to differ this processing (for example using a SQL
Server job that performs some cleanup).

Patrice

--

"karahan celikel" <NO*******************@hotmail.com> a écrit dans le
message de news:eb**************@TK2MSFTNGP11.phx.gbl...

I realized that when SqlServer mode is used for session management
Session_End event is not fired in global.asax.
What can I do if I want to do something when a user's session end?

Thanks

[Alvin Bruney [MVP]]

No not really, these events aren't necessarily paired. It's a common
misunderstanding on the part of developers. Here's a link to an explanation
of the session end event and when it fires. That may help clear up some of
your confusion.
http://www.developersdex.com/gurus/articles/746.asp

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Karahan Celikel" <NO*******************@hotmail.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...

Thanks Alvin and Yan-Hong for your replies.

but isn't it weird that session_start is fired but not session_end?

"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
news:Qt**************@cpmsftngxa07.phx.gbl...

Hello Karahan,

Thanks for posting in the group.

I agree with Alvin that Session_End event is supported only in InProc

mode.

Here is a quick summary of the major things you need to know about picking asp.net session state mode:

Storage location
----------------
InProc - session kept as live objects in web server (aspnet_wp.exe)

StateServer - session serialized and stored in memory in a separate

process

(aspnet_state.exe). State Server can run on another machine

SQLServer - session serialized and stored in SQL server

Performance
------------
InProc - Fastest, but the more session data, the more memory is consumed

on

the web server, and that can affect performance.

StateServer - When storing data of basic types (e.g. string, integer,

etc),

in one test environment it's 15% slower than InProc. However, the cost of serialization/deserialization can affect performance if you're storing

lots

of objects. Have to do performance testing for your own scenario.

SQLServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 25% slower than InProc. Same warning about
serialization as in StateServer.
Robustness
-----------
InProc - Session state will be lost if the worker process (aspnet_wp.exe) recycles, or if the appdomain restarts. It's because session state is
stored in the memory space of an appdomain. Read doc on when such events will happen.

StateServer - Solve the session state loss problem in InProc mode. Allows a webfarm to store session on a central server. Single point of failure

at

the State Server.

SQLServer - Similar to StateServer. Moreover, session state data can
survive a SQL server restart after you've followed instructions in KB
311029.

Caveats
--------
InProc - It won't work in web garden mode, because in that mode multiple
aspnet_wp.exe will be running on the same machine. Switch to StateServer or SQLServer when using web garden. Also Session_End event is supported
only in InProc mode.

StateServer - In a web farm, make sure you have the same <machineKey> in
all your web servers. See KB 313091 on how to do it. Also, make sure

your

objects are serializable. See KB 312112 for details.

SQLServer - If you specify integrated security in the connection string
(e.g. "trusted_connection=true", or "integrated security=sspi"), it won't work if you also turn on impersonation in asp.net. Unfortunately, this

bug

isn't reported in KB yet. (There is a QFE fix for it.) Also, make sure
your objects are serializable. See KB 312112 for details.

Does that answer your question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no

rights.

[Karahan Celikel]

As you said, I need to do some clean-up and also log user activities.
But after thinking about it , I realized that there may be no point to fire
session_end event as Alvin pointed out.
SqlServer mode is used in web farm scenarios with more than one web
application. So it would be ambiguous that which web application will handle
the session_end. event and does clean-up etc. But it would be a great
feature if we could define which web app will be responsible for that event
in web.config file.

and I also would like to have a transparent state management without
considering caveats of each one e.g serialization, same machine keys,
session_end , integrated security.

Anyway, I decided to do the cleanup in sql server side even though that is
somewhat bad for the object orientation.
Thanks

"Patrice Scribe" <no****@nowhere.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

What do you want to do ?

Sometimes it's possible to differ this processing (for example using a SQL
Server job that performs some cleanup).

Patrice

--

"karahan celikel" <NO*******************@hotmail.com> a écrit dans le
message de news:eb**************@TK2MSFTNGP11.phx.gbl...

I realized that when SqlServer mode is used for session management
Session_End event is not fired in global.asax.
What can I do if I want to do something when a user's session end?

Thanks

[Yan-Hong Huang[MSFT]]

Yeah. That is really a good article and explains the behavior. :)

Karahan, do you have any more concerns on it?

Have a good day.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Karahan Celikel]

As you said, I need to do some clean-up and also log user activities.
But after thinking about it , I realized that there may be no point to fire
session_end event as Alvin pointed out.
SqlServer mode is used in web farm scenarios with more than one web
application. So it would be ambiguous that which web application will handle
the session_end. event and does clean-up etc. But it would be a great
feature if we could define which web app will be responsible for that event
in web.config file.

and I also would like to have a transparent state management without
considering caveats of each one e.g serialization, same machine keys,
session_end , integrated security.

Anyway, I decided to do the cleanup in sql server side even though that is
somewhat bad for the object orientation.
Thanks
"Patrice Scribe" <no****@nowhere.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

What do you want to do ?

Sometimes it's possible to differ this processing (for example using a SQL
Server job that performs some cleanup).

Patrice

--

"karahan celikel" <NO*******************@hotmail.com> a écrit dans le
message de news:eb**************@TK2MSFTNGP11.phx.gbl...

I realized that when SqlServer mode is used for session management
Session_End event is not fired in global.asax.
What can I do if I want to do something when a user's session end?

Thanks