469,125 Members | 1,251 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,125 developers. It's quick & easy.

Session_End and SqlServer Session Mode

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
Nov 18 '05 #1
8 8061
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

Nov 18 '05 #2
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.

Nov 18 '05 #3
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.

Nov 18 '05 #4
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


Nov 18 '05 #5
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.


Nov 18 '05 #6
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

Nov 18 '05 #7

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.

Nov 18 '05 #8
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

Nov 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by A | last post: by
4 posts views Thread by John Q. Smith | last post: by
1 post views Thread by Julie Barnet | last post: by
2 posts views Thread by Dave Wright | last post: by
reply views Thread by Jeff Carver | last post: by
4 posts views Thread by Lucas Tam | last post: by
reply views Thread by =?Utf-8?B?QmFsYWpp?= | last post: by
2 posts views Thread by gnewsgroup | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.