views:

219

answers:

4

Hi,

I have a Classic ASP site, that requires some database tables to be emptied out of session data on a schedule. This system doesn't have access to scheduled tasks (it's on a shared web host, and using MySQL server)

I was considering using global.asa, to fire off events as such:

  1. Application_OnStart - delete all session data from database
  2. Application_OnEnd - delete all session data
  3. Session_OnStart - create a user' session
  4. Session_OnEnd - delete all session data that relates to this session.

Is there any reason why I shouldn't create database connections in global.asa? These will be created and destroyed here, no shared on session or application scope. I see it as a way of running these admin tasks twice per user (on session start and end) and not being fired again for them equating to very little database traffic.

Anyone have any ideas as to why this may be bad? Any reasons to not connect to a database in global.asa?

If anyone thinks the above idea is a bad one - do you have any other thoughts as to how I can regularly empty these tables without one or more of:

  1. Scheduled task
  2. Database scheduled task
  3. Running the code on page load for every page (hence the Session_OnStart hooks)

Ta'

Senior Coconut

+1  A: 

It depends on how long your cleanup tasks will take. Since no request will be served while Application_Start is running, it may block for a while.

Moreover, you have no guarantee that Application_End (or Session_End) will be called in all cases (when the server is shut down it may not be fired, or some catastrophic failure may bypass these events entirely).

Best way would be, as you suggest, to run a scheduled task in charge of cleaning up stale session data.

Yann Schwartz
Hi Yann,Good point re: Application_Start slowing things down - I'd not considered that - although unsure what the potential delays are - hopefully short. I would hope that session_end would remove the majority of session data, limiting any delays in Application_Start to a minimum (ie- these queries should be few unless the server crashed)
Senior Coconut
+1  A: 

You could write a web page that empties the session tables, and call that page from an external box via a scheduled task.

RedFilter
This is what we have setup already - however I don't like the dependency on another box to clean up the session data, and wanted to make it a "self contained" solution.
Senior Coconut
+1  A: 

I'd do cleanup for single session in Session_OnEnd and for ALL sessions in Application_OnStart. If your all-sessions-cleanup is slow, you can do a ugly thing and put that cleanup in a separate asp-file that you make a http-request to using the XMLHTTP class, remember to not wait for the request to complete as it won't begin being served before all code in Application_OnStart is run.

svinto
A: 

If you have consistent traffic you can piggyback small tasks at the end of a request cycle. Just issue a response.flush and then execute the db queries. Of course you need to write youre own scheduler. Another option is to create an seperate asp file (tasklet) which you ping using an serverside, async, xmlhttpreq at the start of the request. This keeps the cleanup code out of the clients request cycle and reduces latency.

Actually i woudn't be suprised if there isn't already some clever appengine based webappr/api that can ping youre legacy tasklet/webhooks on schedule. And if there isn't, you could write one youre self, the options are endless :)

Joost Moesker