This is a good point, and was the basis for the original implementation, that the application starts when the first visitor registers a session. This was the definition of the original Application_OnStart event in the ASP model.
That's reasonable.
If I understand things correctly, the real need is to calculate something once per application,
More accurately, the new event would be for calculating something when the web server first comes up.
I was able to actually use the current Application_OnStart in my situation once I understood how it actually behaved. The consequence is simply that I have to nuke the StateDir every time I change Application_OnStart's implementation, to force that event to be re-run.
If I were still working on the code, this would be a fair annoyance. The difference with new event is that it would run every time the parent web server comes up, regardless of whether the "application" is considered to be restarting. Restarting the web server to make new changes appear isn't a problem at all. I have to do it often already, since much of my code is in Perl modules, which don't get reloaded when they change.
Global_OnStart or Global_OnCompile ( Global_OnStart seems consistent )
Global_OnStart is good.
which would be executed when the global.asa is compiled for the first time.
If one wanted this to occur just once per server start, then running Loader()
to get it compiled there would be the trick, otherwise it would be executed
just once per httpd process.
I was thinking Global_OnStart would be in lieu of getting Loader working. Once you get Loader working, code at the end of global.asa has this "once on Apache startup" behavior, doesn't it?
The only gray area would be if you changed global.asa. It gets recompiled in this case. Would Global_OnStart be re-run? I suppose it could work either way.
It may be that necessarily Global_OnStart would have to occur before $Application
or $Session is set up ( effectively before Application_OnStart or Session_OnStart )
effectively. Would this event still be useful if this is the case?
Yes, that's still useful.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
