Hello all,
I am working on a large modperl app, and one of the features of this is a
plugin system that allows others to write and install modules. Everything is
good as far as this goes, but the problem is updateing/deleting modules. It
seems as though the code is cached until an apache restart
On Fri, 2003-08-01 at 13:42, Scott wrote:
I have
looked at Apache::Reload and Apache::StatINC
And what was wrong with them? You should know that there is no perfect
way to reload a Perl module. It just isn't a feature of the language.
Those two modules come as close as you can get without
Scott [EMAIL PROTECTED] writes:
Hello all,
I am working on a large modperl app, and one of the features of this is a
plugin system that allows others to write and install modules. Everything is
good as far as this goes, but the problem is updateing/deleting modules. It
seems as though the
On Tue, 22 Jul 2003 13:05:00 +0300, Stas Bekman wrote:
Peter Haworth wrote:
Cache::Mmap (which I wrote) isn't threadsafe, but should work OK in a
forking MPM. If anyone wants to contribute code to make it threadsafe
(preferably without impacting single-threaded performance too much),
I'll
Sorry to step in here, but could I use any of the caching modules you
mentionned in mod_perl2?
thx
tom
Am Mon, 2003-07-21 um 21.45 schrieb Perrin Harkins:
On Sun, 2003-07-20 at 15:47, Patrick Galbraith wrote:
One thing that my code does is check to see if it's cache has been
updated
On Tue, 2003-07-22 at 02:13, Tom Schindl wrote:
Sorry to step in here, but could I use any of the caching modules you
mentionned in mod_perl2?
I can't vouch for the thread safety of these modules, but all of them
should work in prefork mode.
- Perrin
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 29, 2003 1:19 PM
Subject: mod_perl caching form data?
Hi all,
I'm having a problem with mod_perl 1.2.7 that's baffling me completely,
and I've been searching and reading for days, but I still can't figure
it out. My apologies
Perrin == Perrin Harkins [EMAIL PROTECTED] writes:
Perrin On Thu, 2003-05-29 at 17:26, [EMAIL PROTECTED] wrote:
A simple $cgi-delete('ipaddress') to delete the value when I create
the field has done the trick. Thanks very much to the both of you.
Perrin I'm glad to hear that worked, but it's
On Fri, 2003-05-30 at 10:42, Randal L. Schwartz wrote:
I had been using CGI.pm (through Template::Plugin::CGI), and was
mystified because *occasionally* the wrong picture would show, but a
simple reload fixed it.
I fixed the bug by avoiding CGI.pm, and using Apache::Template's
param
Thus spake Perrin Harkins ([EMAIL PROTECTED]):
Let's not jump to conclusions. We don't have a test case yet, and no
one has seen David's code so he might have a simple global variables
problem.
I suspect that the more likely explanation of this particular problem
is that I goofed up. Anyway,
some fairly
straight-forward mod_perl scripts (using CGI.pm). They take form
data from the user, process it, and stick it in a database (through
DBI).
So far, so good. Everything works pretty well... Except that
something's caching previously entered form data and displaying it back
to me
Quoting David Ressman [EMAIL PROTECTED]:
something's caching previously entered form data and displaying it back
to me as the default values in those same forms. As an example, this
form has a text field that asks for IP addresses, and the text input
will occasionally be filled out
Thus spake Cees Hek ([EMAIL PROTECTED]):
input type=text name=ipaddress value=192.168.1.1
If that value=192.168.1.1 is set in any of your form fields, then
your script is the cuprit. If your form fields don't have the
value=192.168.1.1 set, or it is set to value=, then your browser is
the
Quoting David Ressman [EMAIL PROTECTED]:
It is possible that you are creating your form fields with CGI.pm,
which will use the currently POSTed parameters to prefill the form, or
This sounds like the most likely culprit, even though I haven't
explicitly turned anything on. It's possible
On Thu, 2003-05-29 at 16:40, David Ressman wrote:
That's just the problem. The value= parameter *is* filled out (and
it is being done at the server end as evidenced by the network sniffer.)
Unfortunately, my script is not doing it. Here's what I have in the
script:
print IP Address:
Thus spake Perrin Harkins ([EMAIL PROTECTED]):
CGI.pm uses sticky widgets by default. These are supposed to be cleared
between requests though, by a cleanup handler that CGI.pm uses. Are you
using mod_perl 2, by any chance? I think I see a bug in CGI.pm's
Nope. mod_perl 1.27
But... you
On Thu, 2003-05-29 at 17:26, [EMAIL PROTECTED] wrote:
A simple $cgi-delete('ipaddress') to delete the value when I create
the field has done the trick. Thanks very much to the both of you.
I'm glad to hear that worked, but it's still worrisome that you were
seeing data leak between different
(through
DBI).
So far, so good. Everything works pretty well... Except that
something's caching previously entered form data and displaying it back
to me as the default values in those same forms. As an example, this
form has a text field that asks for IP addresses, and the text input
David Ressman wrote:
something's caching previously entered form data and
displaying it back to me as the default values in those same forms
This is most likely a variable scoping problem as described here:
http://perl.apache.org/docs/1.0/guide/frequent.html
As a rule of thumb, variables
Hi!
On Thu, May 29, 2003 at 12:19:49PM -0500, David Ressman wrote:
So far, so good. Everything works pretty well... Except that
something's caching previously entered form data and displaying it back
to me as the default values in those same forms. As an example, this
form has a text
that there is a new caching module for Apache 2.0, but I am not
ready to upgrade yet and am otherwise quite satisfied with 1.3.x
currently. I am just wondering if there is some magic switch I can throw
for mod_proxy to cache mod_perl content coming from localhost. I have
tried changing the redirect to use the fully
suitability for what I want to do.
The scenario:
I have a large web-site that is largely database driven. Many of the
pages are accessed frequently yet are only modified on average once a
day. The site is written in a variety of technologies including PHP and
Perl.
I wanted to develop a caching proxy
Abdul-wahid Paterson wrote:
I wanted to develop a caching proxy that will return a cached page
instead of passing control to one of the PHP scripts or Perl scripts
that normally generate the pages.
This is called a reverse proxy and is very common in mod_perl setups.
It is typically done
. That is, if the
page is coming from the dynamic webserver then that webserver is going
to create the content and do the authentication/authorisation however
for subsequent visitors I need the caching reverse proxy to do the
authentication. Could you expand on the steps in the apache process
cycle
Abdul-wahid Paterson wrote:
In the docs you cited, it says:
ProxyPass happens before the authentication phase, so you do not have
to worry about authenticating twice.
Hmmm, I thought you had an opportunity to do access control first.
Look at this, from the mod_proxy docs:
with $r-header_out..
Has any one succeeeded is caching dynamic content in this configuration
When I have caching problems, I run my pages through cachability to find out
where they are failing. Check it out at:
http://www.web-caching.com/cgi-web-caching/cacheability.py
It reports on page headers
2002 12:20:01 GMT) by default is the "RFC one" ie the
abbreviation point after day and month needed or not ?
in any case i have tried both form without success
for caching.
Has any one succeeeded is caching dynamic content
in this configuration
thanks
pascal
winxp
perl561/modperl126/apache1326
I'm in a baffled state, ladies and gentleman.
I'm using TT2 to ultimately display some pages, however I'm having some
rather odd behaviour creeping in.
In my template constructor I have CACHE_SIZE set to 0.
I have a page which - even after a server restart - reverts to an older
version of the
.
Sounds like browser caching, or a rather borked transparent proxy. Or both.
- --
Stephen Clouse [EMAIL PROTECTED]
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. http://www.theiqgroup.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux
I'm setting the following headers with mod_perl and there seems to be a bug
in the way netscape 4.7 handles them. The page is being auto refreshed by
Netscape if the document in cache is compared to document on network
preference is set to every time. I've tried IE and I don't seem to have the
Steve Walker wrote:
I'm setting the following headers with mod_perl and there seems to be a bug
in the way netscape 4.7 handles them. The page is being auto refreshed by
Netscape if the document in cache is compared to document on network
preference is set to every time. I've tried IE and
it, although I'm pretty sure that TT2 has it's own caching
mechanism, however in answer to this 'particular question' could you not
overload TT's service object to use the preloaded instantiation similar,
or more specialised than the one above. (SEE ALSO man Template::Service
..probably) :)
fiq
btw
Cahill, Earl wrote:
I would not be opposed to calling a different,
more standard function to check the cache (set up in a more standard way),
and then fetch accordingly.
Look at how the Memoize module does it. You may be able to do something
similar that would allow caching to be added
Hello People,
Need your advise on how to cache a template under mod_perl... Any ideas?
Thanks in advance
-r
At 12:28 PM -0800 3/6/02, Rasoul Hajikhani wrote:
Hello People,
Need your advise on how to cache a template under mod_perl... Any ideas?
Thanks in advance
-r
#startup.pl
open(FILE,/path/to/tmpl);
$MY::TEMPLATE .= while(FILE);
close(FILE);
Provided that you never change $MY::TEMPLATE, this
Robert Landrum wrote:
At 12:28 PM -0800 3/6/02, Rasoul Hajikhani wrote:
Hello People,
Need your advise on how to cache a template under mod_perl... Any ideas?
Thanks in advance
-r
#startup.pl
open(FILE,/path/to/tmpl);
$MY::TEMPLATE .= while(FILE);
close(FILE);
Provided that you
would the above code work in that situation?!
-r
The Template Toolkit package includes it's own caching mechanism. Check out
the pod for Template::Provider on your system. I'm not sure how it works
under mod_perl, but it should be a good place for you to start.
Tim
because I had no GUI.
Thanks... But I use Template Toolkit to generate a dynamic file. How
would the above code work in that situation?!
-r
The Template Toolkit package includes it's own caching
mechanism. Check out
the pod for Template::Provider on your system. I'm not sure
how
Hajikhani [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 06, 2002 1:28 PM
To: [EMAIL PROTECTED]
Subject: Document Caching
Hello People,
Need your advise on how to cache a template under mod_perl...
Any ideas?
Thanks in advance
-r
are much simpler
than those describing how something can be fetched. I would think it
makes more sense to do something along the lines of the Memoize module,
i.e. make it easy to add caching to your existing data fetching modules
(hopefully using a standard interface like Cache::Cache).
- Perrin
something can be cached are
much simpler
than those describing how something can be fetched. I would think it
makes more sense to do something along the lines of the
Memoize module,
i.e. make it easy to add caching to your existing data
fetching modules
(hopefully using a standard interface
but TT has built-in support for caching templates to disk.
TT mailing list: http://www.template-toolkit.org/info.html#lists
TT caching:
http://www.template-toolkit.org/docs/plain/Manual/Config.html#Caching_and_Compiling_Options
--Ade
Hello
Is there an Apache::Net::LDAP type module that would cache LDAP connections?
Something that behaves in the same manner as Apache::DBI
I went searching on cpan and sourceforge but didn't find what I was looking
for.
Thanks in advance.
/--\
|
On Fri, 8 Feb 2002, Remi Godin wrote:
Is there an Apache::Net::LDAP type module that would
cache LDAP connections? Something that behaves in the
same manner as Apache::DBI
how about ResourcePool? it includes a
ResourcePool::Resource::Net::LDAP class.
How can kill If-Modified-Since and E-Tag incoming headers ?
Do I do it in my custom PerlInitHandler module ?
I have a development server and I don't wish anything to be cached (304
messages, not modified).
Right now my Cookies are not set because of this.
10x
Miroslav Madzarevic wrote:
How can kill If-Modified-Since and E-Tag incoming headers ?
Do I do it in my custom PerlInitHandler module ?
I have a development server and I don't wish anything to be cached (304
messages, not modified).
Right now my Cookies are not set because of this.
Ok, I'm a bit slow...
At 03:05 PM 12/12/01 +1100, Rob Mueller (fastmail) wrote:
>>>>
Just thought people might be interested...
Seems like they were! Thanks again.
I didn't see anyone comment about this, but I was a bit surprised by MySQLs good performance. I suppose cachin
Rob Mueller (fastmail) wrote:
And ++ on Paul's comments about Devel::DProf and other profilers.
Ditto again. I've been using Apache::DProf recently and it's been great at
tracking down exactly where time is spent in my program.
One place that Rob and I still haven't found a good solution
One place that Rob and I still haven't found a good solution for
profiling
is trying to work out whether we should be focussing on optimising our
mod_perl code, or our IMAP config, or our MySQL DB, or our SMTP setup,
or
our daemons' code, or...
Assuming that the mod_perl app is the front-end
On Sun, Dec 16, 2001 at 09:58:09AM +1100, Jeremy Howard wrote:
Can anyone suggest a way (under Linux 2.4, if it's OS dependent) to get a
log of CPU (and also IO preferably) usage by process name over some period
of time?
What about BSD Process Accounting (supported in most *nix systems) and
On Sat, Dec 15, 2001 at 08:57:30PM -0500, Perrin Harkins wrote:
One place that Rob and I still haven't found a good solution for
profiling
is trying to work out whether we should be focussing on optimising our
mod_perl code, or our IMAP config, or our MySQL DB, or our SMTP setup,
or
our
I was using Cache::SharedMemoryCache on my system. I figured, Hey, it's
RAM, right? It's gonna be WAY faster than anything disk-based.
The thing you were missing is that on an OS with an aggressively caching
filesystem (like Linux), frequently read files will end up cached in RAM
anyway
Another powerful tool for tracking down performance problems is perl's
profiler combined with Devel::DProf and Apache::DProf. Devel::DProf
is bundled with perl. Apache::DProf is hidden in the Apache-DB package
on CPAN.
Ya know the place in my original comment where I was optimizing a
On Fri, 14 Dec 2001, Perrin Harkins wrote:
The thing you were missing is that on an OS with an aggressively caching
filesystem (like Linux), frequently read files will end up cached in RAM
anyway. The kernel can usually do a better job of managing an efficient
cache than your program can
So our solution was caching in-process with just a hash, and using a
DBI/mysql persistent store.
in pseudo code
sub get_stuff {
if (! $cache{$whatever} ) {
if !( $cache{whatever} = dbi_lookup()) {
$cache{$whatever}=derive_data_from_original_source($whatever);
dbi_save($cache_whatever
On December 14, 2001 03:04 pm, Perrin Harkins wrote:
So our solution was caching in-process with just a hash, and using a
DBI/mysql persistent store.
in pseudo code
sub get_stuff {
if (! $cache{$whatever} ) {
if !( $cache{whatever} = dbi_lookup()) {
$cache{$whatever
with everything mentioned thus far is that they
are almost entirely based around the concept of a single server.
Caching schemes that are both fast and work across multiple servers
and process instances are very hard to find. After reading the eToys
article, I decided that BerkeleyDB was worth a look
of sync for some period
though.
The primary problem with everything mentioned thus far is that they
are almost entirely based around the concept of a single server.
Caching schemes that are both fast and work across multiple servers
and process instances are very hard to find. After reading
The thing you were missing is that on an OS with an aggressively caching
filesystem (like Linux), frequently read files will end up cached in RAM
anyway. The kernel can usually do a better job of managing an efficient
cache than your program can.
For what it's worth, DeWitt Clinton
Some more points.
I'd like to point out
that I don't think the lack of actual concurrency testing is a real problem, at
leastfor most single CPU installations. If most of the time is spent doing other stuff in a request (which
is most likely the case), then on average when a process goes to
On Wed Dec 12, 2001 at 03:05:33PM +1100, Rob Mueller (fastmail) wrote:
I tried out the following systems.
* Null reference case (just store in 'in process' hash)
* Storable reference case (just store in 'in process' hash after 'freeze')
* Cache::Mmap (uses Storable)
* Cache::FileCache (uses
On Wed, Dec 12, 2001 at 03:05:33PM +1100, Rob Mueller (fastmail) wrote:
I sat down the other day and wrote a test script to try out various
caching implementations. The script is pretty basic at the moment, I
just wanted to get an idea of the performance of different methods.
Rob, wow
comparable.
I'm not sure what a 'standard table' in MySQL is any more... Berkeley,
MyISAM, ISAM... I guess we can try all these, but that's benchmarking the DB
rather than the caching scheme, and we're not about to try every DB server
we can find!
,
i.e. a single scalar value.
I'm not sure what a 'standard table' in MySQL is any more... Berkeley,
MyISAM, ISAM... I guess we can try all these, but that's benchmarking the
DB
rather than the caching scheme, and we're not about to try every DB server
we can find!
No, of course not. It may
In general the Cache::* modules were designed for clarity and ease of
use in mind. For example, the modules tend to require absolutely no
set-up work on the end user's part and try to be as fail-safe as
possible. Thus there is run-time overhead involved. That said, I'm
certainly not
a url-directory mapping
somewhere.
uh, why couldn't Apache::CacheContent just set
$r-filename(/where/we/put/the/cache/$file) ?
If you add Bill's suggestion about caching on args, headers and
whatnot you would (on some filesystems) need something like that
anyway to make a hashed directory tree
how this interacts with the built-in access control logic .
If you add Bill's suggestion about caching on args, headers and
whatnot you would (on some filesystems) need something like that
anyway to make a hashed directory tree.
Right. A more elaborate Apache::CacheContent would have
On Tue, Dec 11, 2001 at 02:31:36AM -0800, Paul Lindner wrote:
Right. A more elaborate Apache::CacheContent would have a filename
hash function, and a separate cache directory structure along the
lines of Cache::FileCache.
Just curious -- any reason not to use Cache::Cache as the persistance
Paul Lindner wrote:
[snip]
I suppose that one could put the whole uri-cachefile mapping into a
custom PerlTransHandler and leave Apache::CacheContent as-is..
yeah, I think that we're starting to talk about two different
approaches now. the cool thing about the current logic is that no
Just thought people might be
interested...
I sat down the other day and wrote a test
script to try out various caching implementations. The script is pretty basic at
the moment, I just wanted to get an idea of the performance of different
methods.
The basic scenario is the common mod_perl
I sat down the other day and wrote a test script to try
out various caching implementations.
Very interesting. Looks like Cache::Mmap deserves more attention (and
maybe a Cache::Cache subclass).
Have I missed something obvious?
Nothing much, but I'd like to see how these numbers vary
Just wanted to add an extra thought that I
forgot to include in the previous post.
One important aspect missing from my tests
is the actual concurrency testing. In mostreal world programs, multiple
applications will be reading from/writing to the cache at the same time.
Depending on the
One important aspect missing from my tests is the actual concurrency
testing.
Oh, I guess I should have checked your code. I thought these were
concurrent. That makes a huge difference.
2. Lock some part of cache for a request
(Cache::Mmap buckets, MLDBM pages?)
MLDBM::Sync locks the
Hi,
I would like to propose a new Apache module before I send it off to
CPAN. The name chosen is Apache::CacheContent.
It's pretty generic code, and is intended to be subclassed. It
handles the gory details of caching a page to disk and serving it up
until it expires.
It's derived from
I would like to propose a new Apache module before I send it off to
CPAN. The name chosen is Apache::CacheContent.
This is very cool. I was planning to write one of these, and now I don't
have to. Your implementation is short and interesting. I was planning to
do it with a PerlFixupHandler
At 08:19 AM 12/06/01 -0800, Paul Lindner wrote:
Ok, hit me over the head. Why wouldn't you want to use a caching proxy?
BTW -- I think where the docs are cached should be configurable. I don't
like the idea of the document root writable by the web process.
Bill Moseley
mailto:[EMAIL
On Thu, 06 Dec 2001 10:04:26 -0800
Bill Moseley [EMAIL PROTECTED] wrote:
BTW -- I think where the docs are cached should be configurable. I don't
like the idea of the document root writable by the web process.
Maybe:
Alias /cached /tmp/cache
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
On Thu, 6 Dec 2001 08:19:09 -0800
Paul Lindner [EMAIL PROTECTED] wrote:
I've attached a README below. To download it go to
http://www.modperlcookbook.org/code.html
Nice one. here's a patch to make the sample code work :)
--- CacheContent.pm~Thu Dec 6 22:11:35 2001
+++ CacheContent.pm
On Thu, 6 Dec 2001, Paul Lindner wrote:
On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote:
At 08:19 AM 12/06/01 -0800, Paul Lindner wrote:
Ok, hit me over the head. Why wouldn't you want to use a caching proxy?
Apache::CacheContent gives you more control over the caching
At 10:33 AM 12/06/01 -0800, Paul Lindner wrote:
On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote:
At 08:19 AM 12/06/01 -0800, Paul Lindner wrote:
Ok, hit me over the head. Why wouldn't you want to use a caching proxy?
Apache::CacheContent gives you more control over the caching
On Thu, Dec 06, 2001 at 10:47:35AM -0800, Bill Moseley wrote:
Ok, hit me over the head. Why wouldn't you want to use a caching proxy?
Apache::CacheContent gives you more control over the caching process
and keeps the expiration headers from leaking to the browser.
Ok, I see.
Or maybe
On Thu, 6 Dec 2001, Paul Lindner wrote:
On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote:
At 08:19 AM 12/06/01 -0800, Paul Lindner wrote:
Ok, hit me over the head. Why wouldn't you want to use a caching proxy?
Apache::CacheContent gives you more control over the caching
Hello,
PLThat's the price you pay for this functionality. Because we use
PLApache's native file serving code we need a url-directory mapping
PLsomewhere.
PL
PLOf course you don't need to make the entire docroot writable, just the
PLdirectory corresponding to your script.
Apologies if this is
On Thu, Dec 06, 2001 at 12:55:25PM -0800, Andrew Ho wrote:
Hello,
PLThat's the price you pay for this functionality. Because we use
PLApache's native file serving code we need a url-directory mapping
PLsomewhere.
PL
PLOf course you don't need to make the entire docroot writable, just the
Hi
Does anybody know why Apache::Registry caches compiled scripts by their URI, instead
of by their absolute path?
At my site we have quite a lot of virtual hosts, which use the same base of cgi
scripts. This causes the same scripts to be compiled and cached several times (one
time for each
Nicholas Oxhj [EMAIL PROTECTED] said something to this effect on 10/11/2001:
Does anybody know why Apache::Registry caches compiled scripts
by their URI, instead of by their absolute path?
Try Apache::RegistryNG, which caches scripts by their filename.
(darren)
--
Premature optimization is
Does anyone know if there is a perl module that implements HTTP/1.1
caching? I'd like to use one with Apache::ProxyRewrite and don't want to
reinvent the wheel. :)
Regards,
Christian
-
Christian Gilmore
Team Lead
Web Infrastructure Tools
IBM Software Group
, the _session_id has to be the same
FOR EVERY PROCESS in order for the locking to work as desired, for a given
shared data structure.
So my new caching code is at the end of this message.
***OH WOW!*** So, DURING the course of composing this message, I've
realized that the function
The _session_id is used as the seed for the locking semaphore.
*IF* I understood the requirements correctly, the _session_id has
to be the same FOR EVERY PROCESS in order for the locking to work
as desired, for a given shared data structure.
Only if you want to lock the whole thing,
Uhh... good point, except that I don't trust the Cache code. The AUTHOR
isn't ready to put his stamp of approval on the locking/updating.
That sort of hesitancy is typical of CPAN. I wouldn't worry about it. I
think I remember Randal saying he helped a bit with that part. In my
On Tue, Sep 04, 2001 at 12:14:52PM -0700, Rob Bloodgood wrote:
***OH WOW!*** So, DURING the course of composing this message, I've
realized that the function expire_old_accounts() is now redundant!
Cache::Cache takes care of that, both with expires_in and max_size. I'm
leaving it in for
What about my IPC::FsSharevars? I've once mentioned it on this list,
but I don't have the time to read all list mail, so maybe I've missed
some conclusions following the discussion from last time.
I remember the post and went to find IPC::FsSharevars a while ago and was
un-intrigued when I
At 20:37 Uhr -0400 4.9.2001, Geoffrey Young wrote:
I remember the post and went to find IPC::FsSharevars a while ago and was
un-intrigued when I didn't find it on CPAN. has there been any feedback
from the normal perl module forums?
I haven't announced it on other forums (yet). (I think it's
Christian == Christian Jaeger [EMAIL PROTECTED] writes:
Christian I haven't announced it on other forums (yet). (I think it's
Christian more of a working version yet that needs feedback and some
Christian work to make it generally useable (i.e. under
Christian mod_perl). Which forum should I
written file.
I don't think Cache::Cache has enough logic for an atomic
read-modify-write in any of its modes to implement (for example) a
web hit counter. It has only atomic write. The last write wins
strategy is fine for caching, but not for transacting, so I can see
why Rob is a bit puzzled.
It'd
I don't think Cache::Cache has enough logic for an atomic
read-modify-write in any of its modes to implement (for example) a
web hit counter. It has only atomic write. The last write wins
strategy is fine for caching, but not for transacting, so I can see
why Rob is a bit puzzled.
In his
tire of helping you!)
the only reason i discovered this was because i wanted to change the
number of child processes to only one. which brings me to:
2)
im experiencing some heavy modoule-caching annoyance i guess. if i run the
simple hello.pm (see below) and make a very small change
-caching annoyance you speak of is the basic reason for the
existence of mod_perl ... the idea is that the perl code in your module
only gets compiled once rather than every time a user requests the URI.
true, but if it *never* gets recompiled there are reasons to worry.
There are quite a lot of talk
heavy modoule-caching annoyance i guess. if i run the
simple hello.pm (see below) and make a very small change - the change
might take effect immediately in the browser but more frequently it will
show a random cached version of the page.
(i noticed a pattern in my access_log that the very last number
hey guys
i have a pretty big mod_perl system up and running and have run into a
weird problem with browser caching (or rather, not caching) on windows.
i have a series of complex forms that submit to and are generated by a
mod_perl handler. each submitted form is validated and another form
1 - 100 of 157 matches
Mail list logo
