.net framework to core, what about session.onend() on a business app?

Question

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.

Thoughts?

What I have tried:

Considering this, we are sticking to .NET Framework for the moment.

Posted 14-Feb-23 21:38pm

PGagliardi

Add a Solution

Comments

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)

[no name] 15-Feb-23 12:29pm

If your sessions aren't "stateless", then you have to track session activity; and "end" the session if there is no activity. If your sessions (i.e. transactions) were stateless, you would build up and tear down in one go (atomic).

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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