Собираю материал по Memory Consistency Models of IMDGs

Собираю материал по Memory Consistency Models of IMDGs.
Помогите кто чем богат:)

В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.

Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).

В квартете ACID для RDBMS свойства C+I обеспечивались при помощи Transaction Isolation Levels. B ANSI SQL 92 - 4 штуки, в реальности больше (тут на странице 9 - 7штук).

А как IMDG обеспечивают хоть какой-то C+I, и главное КАКУЮ MemModel? Все понимают, что per-producer-per-item-FIFO есть, но что еще?

Пока нарыл:
- IBM WebSphere eXtreme Scale
----> Constrained Tree Schemas (CTS) and applications (CTA) for extreme OLTP (XTP)
----> "IBM WebSphere eXtreme Scale 6" Chapter 8: "Data Grid Patterns" (скачать не удалось, частично главу можно почитать тут, повторяют идею с Constrained Tree Schemas (CTS))


- Oracle Coherence
----> "Oracle Coherence 3.5" Chapter 4 "Implementing Domain Objects" предлагают:
class Customer{
int getAccountId();
int getId();
}
class Account {
int getId();
}
// code
Customer c = imdg.get(...);
Account a = imdg.get(c.getAccountId());
А важный вопрос о том, как сделать что бы к моменту появления Customer уже был доступен его Account не поднимается.
----> Coherence<-JCache<-OCS4J(2.0) ("2.3. Distributed Cache Consistency" at p9) + "Cached Object Consistency Levels"[copy]
----> Coherence Book: terms {application's data structures, data
access patterns}
----> Coherence Book: Optimistic Cache: "The Optimistic Cache service is very similar to the Replicated Cache service, except that it doesn't provide any concurrency control. It is rarely used in practice, so we will not discuss it separately."
----> Coherence Book: Replicated Cache/Read: "Replicated caches have excellent, zero-latency read performance because all the data is local to each node..."
----> Coherence Book: Replicated Cache/Write: "In order to perform write operations, such as put, against the cache, the Replicated Cache service needs to distribute the operation to all the nodes in the cluster and receive confirmation from them that the operation was completed successfully."
----> Coherence Book: Near Cache/Read: "the near cache is a named cache implementation that caches a subset of the data locally and responds to read requests for the data within that subset directly, without asking the Partitioned Cache service to handle the request."
----> Coherence Book: Near Cache/Invalidation: "Coherence provides several invalidation strategies that allow the front tier of a near cache to evict stale objects based on the changes to the master copy of those objects, in a back-tier partitioned cache. [None, Present("One thing to keep in mind is that the invalidation events are sent asynchronously, which means that there is still a time window (albeit very small, typically in the low milliseconds range) during which the value in the front cache might be stale."), All(async too), Auto("switches between Present and All based on the cache statistics".)]"
----> Coherence Book: Continuous Query Cache: "is conceptually very similar to a near cache. For one, it also has a zero-latency front cache that holds a subset of the data, and a slower but larger back cache, typically a partitioned cache, that holds all the data. Second, just like the near cache, it registers a listener with a back cache and updates its front cache based on the event notifications it receives."

- Infinispan
----> Infinispan<-JCache
----> Asynchronous API
----> Map/Reduce over Infinispand


- GemFire
----> Does GemFire Enterprise guarantee message ordering? Events and messages in a GemFire distributed system always maintain update ordering.