New cache relationship - spouse?

From: Stewart Forster <>
Date: Mon, 18 Nov 1996 12:03:02 +1100


        In the vein of using multiple cache machines to handle large demands,
we have the problem of how to guarantee that two (or more) caches will use the
data that the other cache has effectively. Due to many factors, the two
caches can end up with the same copies of objects, which will forever sit in
the cache (under beta19), because IMS_HITs will ensure that the object stays
there (I may be wrong on this, please correct me).

        What would be good would be upon a HIT (UDP or TCP) on a possibly
stale object, the cache would ask its spouse(s) if they had a newer copy
of the data, as well as the source based IMS GET. The protocol would then

1) If the source has the newest object, get that and cache it. (as usual)
2) If a spouse has a newer object than me (and the source is not newer than
   my spouse's copy), get the spouse's copy and remove my copy of the object
   from the swap.
3) If my copy is newer than everyone else's, simply return it. (as usual)

        Basically this an addition of an extra check with the spouses, which
otherwise act the same as the current sibling definiton. This would allow for
a more coherent management of objects across several closely connected caches.

        Do people think this would be good thing to see? I foresee that as
caches increase in popularity, we will start running into the same barriers
with a single machine being asked to handle too much load (much as is
happening right now with web servers) and thus the need to start load sharing
(and coherently managing that) will become necessary. The sibling relationship
is a good start, but we (at Connect) believe spouse-ing may be the next step.



Stewart Forster (Security and Web Proxy Cache Administrator) pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email:   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666
Received on Sun Nov 17 1996 - 17:03:44 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:34 MST