perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Skylos the Doggie <>
Subject Re: Puzzling global.asa and Application behavior
Date Fri, 19 Sep 2003 23:05:28 GMT
(sorry about the delay in my reply, much thought and testings...)

On Thu, 18 Sep 2003, Josh Chamas wrote:

> Skylos the Doggie wrote:
> >
> > First.  Touching the global.asa file does *not* result in a recompile *or*
> > an application-reset.  On IIS it did.  This was quite puzzling for awhile,
> > but I found a workaround.  (shut down web server, delete the StateDir
> > directory contents, and start the web server.)  Obviously, I cannot do
> > this when I'm in production mode.
> When touching the global.asa, it will recompile, but this does not
> trigger an Application_OnStart.

That makes a strange sort of sense... but isn't what I think it should do.

> Application_OnStart only occurs just before the first Session_OnStart,
> and the Application_OnEnd occurs just after the last session's
> Session_OnEnd.  However, this makes these events largely useless, and it
> seems the standard for what these do has changed, so if you need the
> change it would be something worth adding to Apache::ASP.


Well, I know that sometimes, I want to force the application to reset.  I
think that the modification change on the global.asa is a good,
not-happen-normally sort of event.  If this file has changed, we want to
do SOMETHING.  I think that the changing of this file should terminate the
application - run the old application_onend if you like, even all the
session_OnEnd's (yes, I think all the sessions should terminate too)
Particularly in development, being unable to triggur this OnStart event
without jumping through hoops is very fustrating.  And If I do make a
change to this central file, I want its changes to take effect

> > Second.  My application data occaisonally vanishes for no perceptible
> > reason.  I have been testing some routines today that modify a single
> > collection element.  And now for the third time I have had my
> > application data mysteriously vanish out of the program environment.
> > Rather than
> Right, every time there is a new first $Session created for the app, the
> $Application will be reset.

Thats okay, but thats not whats happening.  When THAT happens, everything
is cool.  I'm saying, my application data vanishes, when I have active

But I think I know what happened in perspective of StateDir... more than
one global.asa set of sub-sessions pointing to the same statedir could
result in one application clearing out the application object as it
Application_OnStarts... and the other application just has its
server/application file cleared out, so its tied value is gone.

Yes? No? Possible ?

> > Lastly.  Out of necessity, due to the limitations of PerlScript on
> > windows, I stored all my data structures in the application data as
> > Data::Dumper-ed strings.  (it would just result in HASH(0x...)
> > otherwise) Do I have to continue to do this?
> For 400K data, you could do something like:
> # global.asa
> use vars qw($DATA);
> $DATA = &read_data();
> This might be a bit slow however.  What this will do is each time the
> global.asa is compiled per process, the data will be read & loaded.

Hmm.  Allow me to clarify.  I have data, various parts of which need to be
available for various scripts.  It may be updated.  Not regularly or
frequently, but *while* the application is running.  I don't think a
compile-time read-and-load will be appropriate, because I'd have to
initiate recompile somehow in order to update the data in memory.

> An optimization to make this not an issue is to precompile your
> Apache::ASP application at server startup. ( see TUNING section )  Then
> this data would be shared across the parent/child server processes.

...I'd have to restart the server whenever I modify a file...

Perhaps with production sites with performance issues, but not for me now,
I think.  :)

> If you are finding that this is not good enough, you could try something
> like:
> use vars qw($DATA);
> sub Script_OnStart {
>     $DATA = $Application->{DATA};
>     unless($DATA) {
>        $DATA = &read_data()
>        $Application->{DATA} = $DATA;
>     }
> }

Thats an interesting idea for a workaround, but I'm glad I don't have to
do that.

> > QUESTION FOUR: With Apache::ASP are these stored as referenced
> > entities that persist?
> in the above example with $Application, the data will persist, and the
> underlying Data::Dumper deserialization will be done for you, so it can
> be quite expensive to store 400K worth and to recover that in one go.
> The default DBM will not work for this much data, SDBM_File, so you
> might want to set StateDB to DB_File or GDBM_File depending on what you
> have on your system.  You might also point StateDB to a memory file
> system if you have one available.

Yes, DB_File is what I'm using... (I quickly found that DBM didn't work,
within about 5 minutes of starting to play with Apache::ASP)

I like the idea of using a ram disk.  I don't have one set up right now
though.  I'll consider that.  My sites aren't high-volume right now.


- The best part about the internet is nobody knows you're a dog.
  (Peter Stiener, The New Yorker, July 5, 1993)
- Dogs like... TRUCKS!  (Nissan commercial, 1996)
- PGP key:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message