Hi. The touch file will definately work and I've used that myself but
in this case its inelegance bothers me. It's also another touch point
for administration. What I would probably do is put the state
information in the database itself. The script would keep track of the
age of its data and
Scott Gifford wrote:
Colin Wetherbee [EMAIL PROTECTED] writes:
[...]
At the moment (and not in a production environment), every time the
drop-down list is generated for a web page, the script queries the
database to retrieve the entire list of aircraft. I would prefer to
retrieve the list of
I'm not sure what you're suggesting. The first few pages of cache on
CPAN have some modules for caching data in memory and on disk and so
forth, but I don't see how they relate to my problem.
Which is that of notifying all of my application's perl processes when
an update has been
Clinton Gormley wrote:
I'm not sure what you're suggesting. The first few pages of cache on
CPAN have some modules for caching data in memory and on disk and so
forth, but I don't see how they relate to my problem.
Which is that of notifying all of my application's perl processes when
an
Greetings.
I have an application that accesses some relatively static database
tables to create drop-down select lists. As an example, one of these
tables is a list of common commercial aircraft.
At the moment (and not in a production environment), every time the
drop-down list is
Colin Wetherbee wrote:
At the moment (and not in a production environment), every time the
drop-down list is generated for a web page, the script queries the
database to retrieve the entire list of aircraft. I would prefer to
retrieve the list of aircraft when each Perl interpreter starts and
John ORourke wrote:
Colin Wetherbee wrote:
At the moment (and not in a production environment), every time the
drop-down list is generated for a web page, the script queries the
database to retrieve the entire list of aircraft. I would prefer to
retrieve the list of aircraft when each Perl
On Jan 13, 2008 4:19 PM, Colin Wetherbee [EMAIL PROTECTED] wrote:
I thought about the file thing... if the file exists, check its last
modified timestamp; if that timestamp is greater than the stored
timestamp, then update the data from the database. It seems like
unnecessary disk access,
William McKee wrote:
On Sun, Jun 13, 2004 at 03:44:22PM -0700, David Arnold wrote:
When I am working on a cgi-script, sometimes I make a change, then
refresh the script in my browser, only to not see the changes I made in
the script.
Is there some sort of caching going on with Apache?
Hi David,
Ah,
What is described in the link is exactly what I was doing, working on a
module.
Thanks.
At 11:18 AM 6/14/04 +0300, you wrote:
William McKee wrote:
On Sun, Jun 13, 2004 at 03:44:22PM -0700, David Arnold wrote:
When I am working on a cgi-script, sometimes I make a change, then
refresh the
All,
When I am working on a cgi-script, sometimes I make a change, then
refresh the script in my browser, only to not see the changes I made in
the script.
Is there some sort of caching going on with Apache?
I've found that if I restart Apache my changes become visible on the next
refresh.
On Sun, Jun 13, 2004 at 03:44:22PM -0700, David Arnold wrote:
When I am working on a cgi-script, sometimes I make a change, then
refresh the script in my browser, only to not see the changes I made in
the script.
Is there some sort of caching going on with Apache?
Hi David,
That can depend
All,
I have a few modules which cache a few arrays. I want to get around the problem of these arrays staying cached when Apache Restarts gracefully. I can't have the server stop and start, and Apache::Reload isn't really the solution for this problem (or at least I don't think it is).
Has
On Thu, 2004-02-05 at 08:12, Jean-Michel Hiver wrote:
However I am not sure how to go about it... Maybe with a cleanup handler
which would recompute the content and refresh the cache?
Bingo!
Then I have another problem. What if another cleanup handler closed the
database connection before my
14 matches
Mail list logo
