jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hanson Char" <hanson_c...@yahoo.com>
Subject RE: diff between Remote Cache and Lateral TCP Cache
Date Sun, 20 Jun 2004 01:34:34 GMT
>It's explicitly stated that there is no cache consistency with the caches,
>and any and all consistency must be supplied via an external mechanism.

It would be so much better if, in the majority of the use cases, JCS could
provide not only SPEED but also CONSISTENCY among caches without
compromising speed.  And that users of JCS don't need to worry about
locking, etc., knowing that eventually JCS would automatically take care of

By "majority of use cases" I refer to scenario like a dozen of machines in a
clustered environment, and not the extreme case like Google, which I can't
imagine will ever use JCS anyway.  So the "google" case is really a fantasy
land.  To be really useful, JCS should cover the typical cases (ie SPEED,
CONSISTENCY among cases, and also THREAD-SAFETY.)

Consistency doesn't have to imply synchronous operations, as there is always
a latency from the moment of inconsistency to consistency.  eg it would be
nice if, say, it is guaranteed that all active local caches can have the
local copies made consistent with the latest every 10 minutes or so.

>But 'speed' isn't the point of lateral cache.
>The point is to treat all 'lateral' caches as distributed indexes,
>not redundant stores (which is what Remote Cache does).
>It's strictly a way of making several distributed indexes appear like one
big index on the get.

If speed isn't the point, "lateral cache" should be renamed to "lateral
index", an inconsistent index by the way.  How useful will that be ?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message