On Oct 29, 3:22 pm, Ben Manes <[EMAIL PROTECTED]> wrote:
> That is a caching problem, since the worst case the data is lost and you make
> too many service calls. As long as it is acceptable to lose data as it can
> be recreated, then a cache like memcached works quite well.
Exactly.
>
> In our SOA environment, we have something similar to what you want. The
> service definition may opt-in to support near caching (in-memory + memcached)
> where a miss invokes the service. At the service's side, it may also be
> using the caching layers where a miss invokes the database. Since the
> services most likely reside on different functional clusters, we've been
> using only expiration for near caching rather than having to broadcast the
> invalidation message across clusters. This works pretty well for services
> where eventual consistency is acceptable.
I had thought I'd need invalidation broadcast, but now that you
mention it, if the data is stale for a few minutes then the world
won't end, so putting a 15 minute TTL on the cache entries would be
fine and should give me a plenty juicy performance boost.
How do I make memcached access the "data store" via SOAP or REST
instead of making a database call?
