Re: [Eaccelerator-users] What exactly determines page caching

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Yes, I should have mentioned, doing an _rm() before your _put() calls should
completely eliminate the problem (but of course is a workaround more than a
fix - be aware that under high concurrency some processes may try to _get()
keys that have just been deleted but not yet replaced - and from my
experience using eA's _lock() to prevent this is just a recipe for Apache
deadlocks).

Thomas

----- Original Message ----- 
From: "Hemke, David" <DH...@He...>
To: <eac...@li...>
Sent: Friday, February 23, 2007 4:23 PM
Subject: Re: [Eaccelerator-users] What exactly determines page caching

> Scenario 2, eaccelerator_put()..., sounds like it could describe what we
> are experiencing.  Should we catch the problem again, I'll try your
> suggested check for a duplicate key.
>
> If this turns out to be the case, I take it that it would be safer in
> the future to remove a key before attempting to write/update it.
>
> I believe, we are 2 point releases behind.  I'll see about getting the
> latest installed in our test environment asap.
>
> Thanks for the help.
>
> Dave
>
> -----Original Message-----
> From: eac...@li...
> [mailto:eac...@li...] On Behalf Of
> Thomas Love
> Sent: Friday, February 23, 2007 09:01
> To: eac...@li...
> Subject: Re: [Eaccelerator-users] What exactly determines page caching
>
> If by cached pages you mean using eaccelerator_cache_page($key, $ttl),
> then eA doesn't do anything to determine whether it has changed, it just
> assumes it hasn't, until $ttl seconds are up. If this is what you're
> doing then stale pages should be seen no matter where your dynamic data
> is coming from.
>
> But if you mean that keys stored with eaccelerator_put() are coming back
> stale, then that might be a duplicate key problem. This is when updating
> an existing key creates a new key with the same name instead of
> overwriting the old one. Subsequent _get()s may return the old value,
> with stale data.
>
> To check / eliminate that as a cause, find a key that exhibits this
> behaviour, then do an eaccelerator_rm() to delete the key, and
> immediately another _get(). If the data (any data) is still returned
> after the _rm(), then you have duplicate keys.
>
> I think the duplicate key problem may be fixed in the latest version. I
> haven't seen it myself for a while. If you have the latest eA, then at
> least be sure you aren't running out of space in your cache because I
> have a vague memory of that being a correlating factor.
>
> Cheers
> Thomas
>
>
> ----- Original Message -----
> From: "gg15" <gg...@gm...>
> To: <eac...@li...>
> Sent: Friday, February 23, 2007 8:24 AM
> Subject: Re: [Eaccelerator-users] What exactly determines page caching
>
>
> > Hi
> >
> > You have to determine in your application if the data/page has
> changed?!
> > ... or did I understand you wrong? Oo
> >
> >
> > Bye, Uli
> >
> >
> >
> >
> > Hemke, David schrieb:
> > >   I'm new to this list, and was unable to find an answer via archive
> > > search.
> > >
> > >   What exactly determines page caching and if the cached version
> should
> > > be served?   That is, how does the eaccelerator determine if a page
> with
> > > dynamic data has changed?
> > >
> > >   In our situation we cache certain data / keys in the eaccelerator
> > > cache, this data is used across user sessions.  We are also caching
> > > pages.  There does not seem to be a problem with the serving of
> dynamic
> > > pages where DB fetched data is used, but eaccelerator seems to have
> a
> > > hard time recognizing that the eaccelerator cached data / key has
> been
> > > updated so it sometimes serves stale pages.
> > >
> > >   Thanks,
> > >
> > > Dave Hemke
> > > Web Applications Developer
> > > /HealthPlan Services/
> > > dh...@he...
> > > 813-289-1000 x 2118
> > > 800-237-7767 x 2118
> > >
> > >
> > >
>
>
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> eAccelerator-users mailing list
> eAc...@li...
> https://lists.sourceforge.net/lists/listinfo/eaccelerator-users
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_
>
> This e-mail and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed.
> If you have received this e-mail in error please notify the
> originator of the message. This footer also confirms that this
> e-mail message has been scanned for the presence of computer viruses.
>
> Any views expressed in this message are those of the individual
> sender, except where the sender specifies and with authority,
> states them to be the views of HealthPlan Services.
>
> Scanning of this message and addition of this footer is performed
> by SurfControl E-mail Filter software in conjunction with
> virus detection software.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> eAccelerator-users mailing list
> eAc...@li...
> https://lists.sourceforge.net/lists/listinfo/eaccelerator-users