perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Chamas <j...@chamas.com>
Subject Re: Puzzling global.asa and Application behavior
Date Thu, 18 Sep 2003 23:59:03 GMT
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.  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.

> 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.

> 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.
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.

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;
    }
}

> 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.

> Thanks muchly for all your help and assistance that I anticipate
> recieving.  Apache::ASP is a wonderful module, and I hope to make it work
> for my application.  (or my boss and I are going to be really annoyed.
> ;P)

Regards,

Josh

________________________________________________________________
Josh Chamas, Founder                   phone:925-552-0128
Chamas Enterprises Inc.                http://www.chamas.com
NodeWorks Link Checker                 http://www.nodeworks.com


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org


Mime
View raw message