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" <> wrote in message
news:...
> 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" <> wrote in message
> news:%...
> > 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.GetRSWebApp(Session);
> > webAppInfo.Logout();
> >
> > 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
> >
> >
>
>
