Out-of-process State Management Session Cleanup

[knyghtfyre]

Hello,

My company is developing a rather large application with .NET 2.0. We
are expanding to a server farm and are in the process of converting
our application to use an out-of-process session state management with
SQL Server.

We have ran into a problem with the Session_onEnd event. We know it's
not supposed to fire when in an out-of-process mode, but we have a
large amount of code that must be executed to clean the session and to
log some critical data.

Are there any best practises for dealing with such a situation? What
have others done in the past that have helped them keep a session
state that times-out and cleans up afterwards? Is there a possibility
of the SQL Server to keep track of said timeout and execute some clean
up code?

I've been searching for a few days now and have not yet been able to
find any "best practises" for this type of situation, if you know of
any articles, or have any personal experience, any help is
appreciated.

Thanks,
Marc

 

[Lit]

I found out in the past that whenever I have a long running process that
times-out etc... is to split it into smaller parts, organize it better and
Prioritize it.
execute/save the most critical first and then if and when possible is to
queue the rest to a back end process. Window service, Job, etc..

this may or may not help or be possible for what you are doing. It all
depends.

can you save the critical info then process? what happens if the current
user logs back on immediately.
How critical is the last log on session info to the new login session for
the same user.


Lit

 

[bruce barker]

the default session cleanup is a scheduled job with sqlagent. it runs at
a specified interval and just deletes expired sessions. if you look at
the proc its a pretty simple delete. you could replace it with you own
job, that the the session cleanup and ran whatever other code you want.


-- bruce (sqlwork.com)

 

[knyghtfyre]

the default session cleanup is a scheduled job with sqlagent. it runs at
a specified interval and just deletes expired sessions. if you look at
the proc its a pretty simple delete. you could replace it with you own
job, that the the session cleanup and ran whatever other code you want.

-- bruce (sqlwork.com)

Thanks for the responses, I will be looking into that right now.
Anyone else have any ideas?

 

[knyghtfyre]

Thanks for the help so far, here is some more information about the
situation that is giving us a hard time.

We have data being stored in the session that must be transmitted
externally via HTTP (Web Services Call). If the user ends the process
normally, the session-stored information can be controlled and will be
sent correctly. If the session times out, we want what has been stored
so far in the session to be sent. This is where our problem occurs.

By converting to the out-of-process state management there is no way
of .NET knowing when the the session has ended, or when the session
information is cleared. Therefore, the information that must be sent
is never sent and is lost forever.

Is there any way of alerting the .NET application that the session is
being cleared by the SQL Server (Stored Procedure)? Or are there any
other methods that are possible in this particular solution?

Keep in mind that this could be in a web farm, so there is not really
any way of knowing which process is currently in charge of the session
data.

Thanks again,
Marc

 

[knyghtfyre]

Anyone have any ideas? One of the ideas that has been floating around
the office is to use an SQL Dependency to trigger a call back. Anyone
have any information about how I could go about doing this as well as
passing information back to the application?