Variant invalidation and timestamps

I've been investigating making a patch that allows HTCP CLR and the
purge method to invalidate all stored variants of a given URL. The two
possible basic approaches in this situation are:

* Cascading update. Store a list of variants in the base vary object and
delete all of them when requested.
* Invalidation. Delete the base vary object without cascading. It may be
subsequently recreated. On retrieval of a variant, check if it is older
than the base vary object. If it is, delete the variant from the store
and pretend (for the remainder of the request) that it never existed.

I believe invalidation is best, since updates are fast and simple, and
there is no performance penalty on retrievals except for cases when
deferred storage deletion is required.

The problem is that there appears to be no suitable timestamp stored,
which we can use for this comparison. The StoreEntry->timestamp field,
which is stored in STORE_META_STD, is just an adjusted version of the
Date header. It doesn't reflect the local creation date, rather, it is
an estimate of the origin generation date. It is referenced in many
places for expiry calculations.

There is no actual need to use a timestamp: a random GUID or serial
number would work just as well. And in fact the one-second resolution of
a typical timestamp could cause problems if a page is updated twice in
the same second. If squid has no facilities for random GUIDs or
persistent serial numbers, then current_dtime might be the best option.

So my proposal is to add a new metadata item to storage objects, called
say STORE_META_CREATE_DTIME. It could store the timestamp in machine
double-precision format or some machine-independent format, depending on
the preference of the list.

Any comments?

-- Tim Starling
Received on Sat Jan 27 2007 - 10:19:50 MST