-
Notifications
You must be signed in to change notification settings - Fork 2
Implementation details
get(key, value), put(key, value) and delete(key)
http://www.oracle.com/technetwork/database/berkeleydb/overview/index-093405.html
Read me: http://download.oracle.com/docs/cd/E17277_02/html/index.html
N, W, R: http://www.pythian.com/news/15069/replication-is-the-new-durability-thoughts-about-dynamo/
Membership, failure detection etc: http://www.jgroups.org/
Good article from manageability.com summarizing design patterns from Pat Helland's amazing paper Life beyond Distributed Transactions: an Apostate's Opinion.
-
Entities are uniquely identified - each entity which represents disjoint data (i.e. no overlap of data between entities) should have a unique key. Multiple disjoint scopes of transactional serializability - in other words there are these 'entities' and that you cannot perform atomic transactions across these entities.
-
At-Least-Once messaging - i.e. an application must tolerate message retries**italic text and out-of-order arrival of messages.
-
Messages are addressed to entities - that is one can't abstract away from the business logic the existence of the unique keys for addressing entities. Addressing however is independent of location.
-
Entities manage conversational state per party - that is, to ensure idemptency an entity needs to remember that a message has been previously processed. Furthermore, in a world without atomic transactions, outcomes need to be 'negotiated' using some kind of workflow capability.
-
Alternate indexes cannot reside within a single scope of serializability - that is, one can't assume the indices or references to entities can be update atomically. There is the potential that these indices may become out of sync.
-
Messaging between Entities are Tentative - that is, *entities need to accept some level of uncertainty *and that messages that are sent are requests form commitment and may possibly be cancelled.
-
Event-driven architecture