Click here to Skip to main content
15,936,802 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi folks, I know that .Net has dropped the support for the session.OnEnd() event on global.asax because of scalability, distribution, bla bla bla.

The fact is that in some cases I cannot see how to manage the situation other than relying on Session.OnEnd(), for example in a real-life business app I am facing with these tasks on Session end:

- clear locks on records
- clean the temp directory where a large amount of files are generated (on-the-fly reports, etc)

and the big problem is when the user closes the browser without logging out. While I've thinked about a daemon that every X minutes purges the temp dir, with the complication of taking account of the creation date/time of the temp file, the same thing about record locking is more complicated.

Moreover, we are talking about applications that are replicated in a single machine over hundreds of databases and IIS sites, each with a differen temp folder and so on.


What I have tried:

Considering this, we are sticking to .NET Framework for the moment.
Chris Copeland 15-Feb-23 4:40am    
I'm not au fait with ASP.NET particularly but I think any system which depends on waiting for sessions to end in order to clear up resources is a bad system. Sessions should be used for storing metadata associated with a user or anonymous browser session, and should certainly not be locking records in a table or tracking generated files. I'll repeat that just emphasis, in no way should a session be locking table records.
PGagliardi 15-Feb-23 4:53am    
The session of course contains only anonymous data associated to the user (the session cookie), I only need to know when the session ends in order to perform cleaning and manteinance jobs. All the logic and data is on the server side. Moreover, if the system fails (could happen) the locking logic relies on a timestamp from which the system can assume the session is dead.
Chris Copeland 15-Feb-23 5:33am    
Part of the problem is still that there's cleaning that needs to be done when the session ends. In an ideal application, one shouldn't even need to register for a session end event unless it involves removing some table data which tracks the session activity. "perform cleaning an maintenance jobs" is an example of what probably shouldn't be happening when a session ends. This is just my opinion though, I don't know enough about the code base to make any educated suggestions but I would re-evaluate how the application flows if there is cleaning and maintenance to do on a session end. Especially any part of the flow which has any locking tied in with sessions, this is an extremely bad idea which could lead to any number of problems (regardless of whether it's table-level locking, row-level locking, file-locking)
PGagliardi 15-Feb-23 13:24pm    
Which kind of problems are you thinking about? Could you give me an example? Well, I understand one should examine the application in order to understand but i can tell you that is a very large and very complex web application first designed in 2008 on classic ASP and it's 15 years that uses the session end event with no issues at all. My first issue is that the customers (thousands) can generate pdf reports that are stored server-side in temp files, they have to be purged periodically in order to not saturate the storage (and they can be deleted only if the application is sure that the user doesn't need them anymore, naturally when logged out). The fact is that our typical web application mimic a desktop application, which was the target of ASP.Net Webforms, but we use a lot of custom code and no forms components at all, thus the migration to .Net core is not a problem apart from rethinking the session logic.
Chris Copeland 16-Feb-23 4:46am    
Not least of which is what happens if, for any reason, the session end doesn't trigger? To rely on an event like that to clear up resources can be dangerous, especially if you're locking table records. As an alternative, a more appropriate way might be to have a database table which keeps track of uploaded files and they are retained for X hours (could be as short as 1 hour, or as long as 48 hours), and a background job runs every day which looks for files older than X hours and removes them. This would detach the file resources from the session, and also allow you to track uploaded files via the table. But as you say, if this is a large, existing application then it might not be so easy to make such changes (coming from experience, I used to work on a monolithic, 15 year+ application and fortunately we've just started phasing it out, I can understand that sometimes it's not as easy as just "reworking" something)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900