(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.
Hm...
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
immediately.
> > 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
sessions!
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.
Skylos
- [EMAIL PROTECTED]
- 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: http://dogpawz.com/skylos/mykey.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
