Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation

[Honza M. <hon...@ec...>]

On =DAt, 2002-12-31 at 07:52, Mitra wrote:
> I've had some weirdness with old versions of pages being retrieved=20
> from the cache.
>=20
> One thing i notice is that on line 101 of slice.php3 it tests against=20
> nocache when doing a store.
>=20
> If I understand the logic, shouldn't nocache ONLY apply to retrieving=20
> from the cache.
>=20
> I.e. when you do a retrieve you set nocache, and it would ignore the=20
> cached value of the page, but would then cache the new, correct, page?

No, nocache parameter is intended to use really no cache. Nor for get,
nor for store. I offten use noceche parameter for debuging and there is
good oportunity to store some debug messages into chache, if we
implement nocache parameter another way.

If you want, you can implement 'renewcache' parameter or such, which
will behave as you describe.

> It looks like the cache isn't being invalidated as the Spot's are=20
> being changed, this appears to be happening in site/index.php3 which=20
> doesn't appear to be doing any cache invalidation.
>=20
> I'm not sure how to invalidate the cache, since the example I find -=20
> site/modedit.php3:139  seems (if I understand things correctly) to=20
> invalidate the cache for all slices, so I'm guessing I'm=20
> misunderstanding something

That's right - it is not optimal solution, but the only possible. The
modedit for site in not called so often, so I think we can invalidate
whole cache time to time.

Explanation - how cache works:

It uses folowing database structure:
  CREATE TABLE pagecache (
    id varchar(32) NOT NULL, # md5 crypted keystring used as database
                             # primary key (for quicker database   =20
                             # searching)
    str2find text NOT NULL,  # string used to find record on manual
                             # invalidation of cache record
                             # (- it could be keystring)
    content mediumtext,      # cached information
    stored bigint,           # timestamp of information storing
    flag int,                # flag - not used for now
  PRIMARY KEY (id), KEY (stored));

Row example:
  id:       56b6dc163ea533b88227eee94b37bee4=20
  str2find: slice_id=3D11783cf03dbb66773c1219bd8b6f7456=20
  content:  <table width=3D"600"><tr><td colspan=3D3><br><font s...
  stored:   1041798783
  flag:     0


Basicaly - if you store something to the cache, you use=20
  $cache->store($keystring, $content, $str2find);

where:
  $keystring is any string wich fully identifies the resulting
             content (it is all view's parameteres joined into string,
             for example). There is called md5() on $keystring before it
             is stored into database, so the search for the keystring is
             then much quicker.

  $content   is the content which should be generated for $keystring

  $str2find  is some string, which we can use, if we want to invalidate
             some specific cache content

So, if we want to store content of view from slice 16166... we set
$str2find =3D 'slice_id=3D16166...'. Everytime the content of any slice i=
s
changed (new item added, any item in the slice is changed, moved, ...)
the function:
  $cache->invalidateFor($cond)=20
is AUTOMATICALY called by AA, where $cond=3D'slice_id=3D16166...' in our
case.

The invalidateFor function looks for all cache records wich contains the
string 'slice_id=3D16166...' in str2find field (so probably holds any
information from the given slice) and invalidates such records (deletes
it).

Back to the Mitra's question:

> Am I correct in assuming that invalidate call in modedit.php3:139 is=20
> buggy, and that I should add the code
>=20
> $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # database ch=
anged -
>    $cache->invalidate("slice_id=3D".site_id);  # invalidate old cached =
values
>=20
> into index.php3.

Not at all - it is not enough. Site module uses outputs from many
slices/viws, but the site itself do not know, which all slices it uses.
So, if we invalidate cache just for "slice_id=3D".site_id, there probably
remain cached some views, which is used in the site. Such views could
have old values, so if we want to be sure, we have to invalidate whole
cache.

I have to note, this is ONLY the case of changing parameters in site
module settings which is called really seldom. In main site.php3 script
is the invalidation much clever. There we use $slices4cache array which
lists all slices used in the site:

$slices4cache =3D=20
  array( "cee194633366705889fd2f58d428ec05", // Ecn - events'
         "9e9acc045677619191191256ac7cd2ac", // Ecn - authors'
         "04280ba6756556a6dd802607a3b0edd9", // Ecn - banners'
         "8ce38f43331abd2e555c533795313851", // Ecn - prices'
         "6563656767536f6e6e6563742e2e2e2e", // Ecn - about'
         ...);

Then we can use str2find string just like:

"slice_id=3Dcee194633366705889fd2f58d428ec05,slice_id=3D9e9acc04567761919=
1
191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D8ce=
3
8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e2e"

so any change in any listed slice leads to invalidation of the chache
for the current site (which uses this slice, of course).

Last note: all values are cached for maximum 10 minutes (see CACHE_TTL
parameter in config.php3)

   Honza



> I've done this - and it appears to work - but I wanted to check I'm=20
> understanding the cache logic correctly before I commit to CVS.
>=20
> - Mitra
>=20
>=20