Global.asax Session_End().. .

[James Hunter Ross]

Friends,

In our Global.asax file we implement Session_End() which grabs our own
object and then calls our own logout() method to tidy things up. Code is
below. (We wrap this in try/catch, but presently ignore exceptions, perhaps
we'll start logging something to help us figure this out.)

RSWeb.RSWebApp webAppInfo = RSWebApp.GetRSW ebApp(Session);
webAppInfo.Logo ut();

But, it appears that our logout isn't reliably being called, and licenses
are being orphaned. It appears that when a session times-out Session_End()
is not being called. SO my question...

Is it a good idea for us to assume Session_End will always be called? In
what situations might we expect it not to get called? (Process or
application restarts, I would guess, which is fine for us.)

Any words on this will be very much appreciated. Thank you very much for
anytime you spend on this.

James Hunter Ross

[Jeff Siver]

In my experience, I don't use Session End as it isn't that reliable. Having
said that, I haven't tried it in ASP.NET; just in ASP. But, in ASP, it
never worked reliably. Also, I would suspect similar problems in ASP.NET.
One thing I noticed in the SQL Session State implementation is that MS uses
a SQL Job to delete expired sessions instead of tying into the Session End
event. So if they don't use it, I wouldn't use it.

Jeff
"James Hunter Ross" <ja********@one ilsoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Friends,

In our Global.asax file we implement Session_End() which grabs our own
object and then calls our own logout() method to tidy things up. Code is
below. (We wrap this in try/catch, but presently ignore exceptions,
perhaps we'll start logging something to help us figure this out.)

RSWeb.RSWebApp webAppInfo = RSWebApp.GetRSW ebApp(Session);
webAppInfo.Logo ut();

But, it appears that our logout isn't reliably being called, and licenses
are being orphaned. It appears that when a session times-out
Session_End() is not being called. SO my question...

Is it a good idea for us to assume Session_End will always be called? In
what situations might we expect it not to get called? (Process or
application restarts, I would guess, which is fine for us.)

Any words on this will be very much appreciated. Thank you very much for
anytime you spend on this.

James Hunter Ross

[Alvin Bruney - ASP.NET MVP]

On the contrary, it's very reliable. You need to be familiar with the rules
that govern its firing though.
http://support.microsoft.com/default...b;en-us;555082

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

"Jeff Siver" <je********@new sgroups.nospam> wrote in message
news:ON******** ******@TK2MSFTN GP12.phx.gbl...

In my experience, I don't use Session End as it isn't that reliable. Having said that, I haven't tried it in ASP.NET; just in ASP. But, in ASP, it
never worked reliably. Also, I would suspect similar problems in ASP.NET.
One thing I noticed in the SQL Session State implementation is that MS uses a SQL Job to delete expired sessions instead of tying into the Session End
event. So if they don't use it, I wouldn't use it.

Jeff
"James Hunter Ross" <ja********@one ilsoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Friends,

In our Global.asax file we implement Session_End() which grabs our own
object and then calls our own logout() method to tidy things up. Code is below. (We wrap this in try/catch, but presently ignore exceptions,
perhaps we'll start logging something to help us figure this out.)

RSWeb.RSWebApp webAppInfo = RSWebApp.GetRSW ebApp(Session);
webAppInfo.Logo ut();

But, it appears that our logout isn't reliably being called, and licenses are being orphaned. It appears that when a session times-out
Session_End() is not being called. SO my question...

Is it a good idea for us to assume Session_End will always be called? In what situations might we expect it not to get called? (Process or
application restarts, I would guess, which is fine for us.)

Any words on this will be very much appreciated. Thank you very much for anytime you spend on this.

James Hunter Ross