If not code could you please provide some generic explanation?
views:
499answers:
4The most common example is counting the online users. Incrementing the count on Session_Start
and the opposite on Session_End
.
Session_Start Collection all user information and storing in database. Preparing system for user like temporary file, cached file.
Session_End Saving user state in database. Cleaning system and etc.
In Session_Start you can setup anything relevant for a session, depends very much on the application.
In general you should avoid Session_End if possible, not only will it generally fire very late (after a session timeout) but in a multi-server configurations it will not fire at all.
For details, see the SessionState tag in Web.config
It's always good to remind ourselves why we should never use Session_End
excert from Understanding session state modes + FAQ
- Session_End event is only supported in InProc mode.
- Session_End won't be fired if you close your browser. HTTP is a stateless protocol, and the server has no way of knowing if the browser has closed or not.
- Session_End will be fired only:
(a). After n minutes of inactivity (n = timeout value),
or
(b). If someone calls Session.Abandon(). - For case (a) (Point 3), Session_End will be run by a background thread, which implies: (a). Your code in Session_End is running using the worker process account. You may have permission problem if you're accessing resource such as database. (b). If an error happens in Session_End, it will fail silently.
- For case (b) (Point 3), in order for Session_End to be fired, your session state has to exist first. That means you have to store some data in the session state and has completed at least one request.
- Again for case (b) (Point3), Session_End will be called only if the abandoned session is actually found. As a result, if you create and abandon a session inside the same request, because the session hasn't been saved and thus can't be found, Session_End won't be called. This is a bug in .NET Framework 1.0 and 1.1.