Comments on: Eventual Consistency Is Just Caching http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/ Enterprise Development Expert & SOA Specialist Wed, 08 Sep 2010 18:14:32 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: udidahan http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/comment-page-1/#comment-37057 udidahan Sun, 28 Feb 2010 14:24:30 +0000 http://www.udidahan.com/?p=1182#comment-37057 Jeff, There are distributed caches that actually provide this. The fact that memcached doesn't can be taken a single anecdote - no proof either way. The "get over it" was *not* to say to people "you don't need to learn how caches work". Rather, that people make such a fuss about eventual consistency and how much more complicated it makes things, but use caches that have similar consistency effects without thinking twice. It was to those people who I was saying "get over it". Jeff,

There are distributed caches that actually provide this. The fact that memcached doesn’t can be taken a single anecdote – no proof either way.

The “get over it” was *not* to say to people “you don’t need to learn how caches work”. Rather, that people make such a fuss about eventual consistency and how much more complicated it makes things, but use caches that have similar consistency effects without thinking twice. It was to those people who I was saying “get over it”.

]]> By: Jeff Darcy http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/comment-page-1/#comment-37056 Jeff Darcy Sat, 27 Feb 2010 02:02:49 +0000 http://www.udidahan.com/?p=1182#comment-37056 Sorry, Udi, but that's just not an accurate statement. Eventual consistency requires a protocol which completes in bounded time and guarantees that (in the absence of other writes) reads from all nodes will converge on the same value. Many caches lack such a protocol and can remain inconsistent with their underlying stores indefinitely. Memcached is the best known example of a cache deployed "when the database can't handle it" and fits into this category. That's not eventual consistency; that's no consistency at all. "Get over it" is a poor excuse for failing to learn about an important piece of technology. Sorry, Udi, but that’s just not an accurate statement. Eventual consistency requires a protocol which completes in bounded time and guarantees that (in the absence of other writes) reads from all nodes will converge on the same value. Many caches lack such a protocol and can remain inconsistent with their underlying stores indefinitely. Memcached is the best known example of a cache deployed “when the database can’t handle it” and fits into this category. That’s not eventual consistency; that’s no consistency at all. “Get over it” is a poor excuse for failing to learn about an important piece of technology.

]]> By: udidahan http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/comment-page-1/#comment-37045 udidahan Tue, 23 Feb 2010 17:12:50 +0000 http://www.udidahan.com/?p=1182#comment-37045 Mark, This post is primarily to ask for a reality check on developer reticence around eventual consistency. For a broader discussion on eventual consistency, see my posts on CQRS. > the user will naturally attempt to create another client > again resulting in duplicates It won't result in duplicates if the command-side contains logic which prevents it. The command-side is responsible exactly for preventing the kinds of race conditions you described. This can be as simple as a unique constraint in its DB. Hope that answers your questions. Mark,

This post is primarily to ask for a reality check on developer reticence around eventual consistency. For a broader discussion on eventual consistency, see my posts on CQRS.

> the user will naturally attempt to create another client
> again resulting in duplicates

It won’t result in duplicates if the command-side contains logic which prevents it. The command-side is responsible exactly for preventing the kinds of race conditions you described. This can be as simple as a unique constraint in its DB.

Hope that answers your questions.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #544 http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/comment-page-1/#comment-37040 The Morning Brew - Chris Alcock » The Morning Brew #544 Mon, 22 Feb 2010 08:41:28 +0000 http://www.udidahan.com/?p=1182#comment-37040 [...] Eventual Consistency Is Just Caching - Udi Dahan cuts through all the bother about Eventual Consistency reminding us that Eventual Consistency is what we have whenever we Cache. [...] [...] Eventual Consistency Is Just Caching – Udi Dahan cuts through all the bother about Eventual Consistency reminding us that Eventual Consistency is what we have whenever we Cache. [...]

]]> By: Eventual consistency is just caching ? | Scalable web architectures http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/comment-page-1/#comment-37039 Eventual consistency is just caching ? | Scalable web architectures Mon, 22 Feb 2010 04:53:07 +0000 http://www.udidahan.com/?p=1182#comment-37039 [...] caching, eventually consistent So there is someone who thinks “eventual consistency is just caching”.  Though I liked the idea of discussing this, I don’t agree with Udi’s views on [...] [...] caching, eventually consistent So there is someone who thinks “eventual consistency is just caching”.  Though I liked the idea of discussing this, I don’t agree with Udi’s views on [...]

]]> By: Mark Phillips http://www.udidahan.com/2010/02/21/eventual-consistency-is-just-caching/comment-page-1/#comment-37037 Mark Phillips Mon, 22 Feb 2010 03:03:50 +0000 http://www.udidahan.com/?p=1182#comment-37037 Hi Udi, I understand the need for data cache for performance reasons but often it is just not appropriate to use it in all cases. You wouldn't cache your entire domain would you, or is this how we should be treating the UI views in your opinion? As nice as this may sound it stands in the face of some customer requirements such as the need to see an updated view of records that they may have just added a record to. To explain further I'll pose a real scenario: A user must perform a search for a client (against the query side I'm assuming) to use in some business context. If they cannot find the client via some search then a new client is to be created by the user and used in the process. So, if the user creates this new client and then performs a search for that client only to not find it because the cache/readonly view/query side or whatever does not reflect the new data yet, the user will naturally attempt to create another client again resulting in duplicates. This is not acceptable to the business and is (one of) the reason eventual consistency doesn't help at times. Mark Hi Udi,

I understand the need for data cache for performance reasons but often it is just not appropriate to use it in all cases. You wouldn’t cache your entire domain would you, or is this how we should be treating the UI views in your opinion?

As nice as this may sound it stands in the face of some customer requirements such as the need to see an updated view of records that they may have just added a record to. To explain further I’ll pose a real scenario:

A user must perform a search for a client (against the query side I’m assuming) to use in some business context. If they cannot find the client via some search then a new client is to be created by the user and used in the process. So, if the user creates this new client and then performs a search for that client only to not find it because the cache/readonly view/query side or whatever does not reflect the new data yet, the user will naturally attempt to create another client again resulting in duplicates. This is not acceptable to the business and is (one of) the reason eventual consistency doesn’t help at times.

Mark

]]>