ASP.Net, Session_End, Sql Server 2003

[howard39]

When SQL Server 2003 is *not* configured in IIS5 isolation mode, is it true
that the Session_End event can not be depended on? If so, what is a good way
to clean up unmanaged resources that were created in abandoned user sessions?

[bruce barker]

Session_End only fires for InProc sessions.

with out of proc session managers (such as sqlserver) , there are no
unmanaged resources to clean up, because the session objects are not
referenced (stored), only their serialization is stored (when you reqest
them from the session, they are deserialized into an object).

if your session objects have unmanaged resourecs (a really bad idea - though
generally they will not serialize and cannot be stored in session anyway),
then you should dispose of them after session serialization (say at
OnUnload - call base first).
-- bruce (sqlwork.com)


<ho******@nospa m.nospam> wrote in message
news:EB******** *************** ***********@mic rosoft.com...
| When SQL Server 2003 is *not* configured in IIS5 isolation mode, is it
true
| that the Session_End event can not be depended on? If so, what is a good
way
| to clean up unmanaged resources that were created in abandoned user
sessions?
|

[Steven Cheng[MSFT]]

Hi Howard,

As Bruce has said, the Session_End event is only supported when we use the
InProcess Session. If you are using out of process session and do need to
control some certain resouce handles (stored in session) when the user's
session timeout or after some certain period. I think we can consider the
following means:
1.Use a cookie value (which set the expiration time as the Session Timeout
period) and check it in each comming request. When the cookie is
unvailable, that means the timeout and then do the release tasks and reset
the cookie.

2. Make use of the asp.net's application Cache which can store some
certain objects in memory and it can also send notify event when a certain
Cached object will be removed from the Cache collection(time out).

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

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

[howard39]

Steven,

Please help me understand this,

Session_End is only supported if we use InProc sessionState mode. If we use
SQLServer mode or StateServer mode, there is no Session_End event. But if we
use InProc sessionState with IS 5.0 isolation mode *not* enabled, then worker
process recycling causes Session_End to come at unpredictable times, making
is effectively useless.

Q: Is the above correct?

Presumably we should aim not to enable IS 5.0 isolation mode, since this is
included for backward compatibility only.

Q: Is this correct?

Checking a cookie value for each incoming request doesn’t help me, because
one of the problems that I am trying to solve is where the user closes their
browser, leaving the unmanaged resources that we created un-disposed. In our
case these unmanaged resources are necessary – we would have had to rewrite
hundreds of thousands of lines of existing code to eliminate the need for
them.

So therefore we should build a new solution that uses Cache plus timeout
notification. So my final question is:

Q: If I do not enable IS 5.0 isolation mode, and I use InProc sessionState
mode, will Session.Session ID be persisted correctly through worker process
recycling? Or do I have to use a cookie to persist SessionID, which I then
use to identify the Session resources that I have stored in Cache?

[Steven Cheng[MSFT]]

Hi Howard,

Thanks for your followup. As for the further question you mentioned, here
is the answers:

1 and 2 :

yes, on win2k3 IIS6 server, the IIS5 process isolation model is for
backward compatibility and it is recommended that we use the IIS6'S
application pool model. And the IIS6'S application pool isolation model can
help protect each application from being affected by other applications on
the same server(host each app in its own application pool)

3: The SessionId can't be persist after process recycle or application's
AppDomain restart. In fact, it'll even change when there is unhandled
exception occurs(Session will restart). Anyway, since the SessionID
maintaining is something invisible to us, I recommend that you implement
your own custom Identity if you need a unchanged token through appdomain/
process restart.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

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

[howard39]

Steven,

Thanks -- I think I have it now.

--Howard

[Steven Cheng[MSFT]]

You're welcome Howard.

Good LUck!

Regards,

Steven Cheng
Microsoft Online Support

[howard39]

Since I'm don’t want to use IIS 5 emulation, I'll have to persist a
session-specific identifier and then use Cache to store data efficiently and
provide the equivalent of a session expiration event:

(1) Use StateServer mode or SQLServer mode or a cookie or a hidden field or
ViewState or query strings to persist my own unique pseudo session ID.

(2) Use the pseudo session ID to label any session-specific data I may store
in Cache, and to label any session-specific unmanaged resources.

(3) On each Page Load, retrieve my pseudo session ID and use it to access
session-specific data from Cache and session-specific unmanaged resources.

(4) Set my session-specific data in Cache to expire after a suitable timeout.

(5) Handle the cache data expiration event to clean up unmanaged resources
for the given session.

Is this correct?

[Steven Cheng[MSFT]]

Hi Howard,

I think this is ok. And another suggestion is you can still use the
SQLSESSION to store the orginal datas and the Cache object is just used to
help provide a session Timer which will notify us when a certain cache
object("Session ") will be expired so that we need to clear those objects in
the Session. Thus, we can avoid storing too many things in cache. How do
you think?

Regards,

Steven Cheng
Microsoft Online Support

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