I’ve already told you about ☞ Chris Gioran’s series on Neo4j internals. Now, he is working on providing support for pluggable JTA compliant transaction managers in Neo4j and details about the current status can be found in his ☞ last post. Anyways, before that he started with a deep dive into the Neo4j transactions and that resulted in 4 (quite long) articles:

• ☞ Write Ahead Log and Deadlock Detection

  In this post I will write a bit about two different components that can be explained somewhat in isolation and upon which higher level components are build. The first is the Write Ahead Log (WAL) and the other is an implementation of a Wait-For graph that is used to detect deadlocks in Neo before they happen.

• ☞ XaResources, Transactions and TransactionManagers

  This time we will look into a higher level than last time, discussing the Transaction class and its implementations, Commands and TransactionManagers, touching a bit first on the subject of XAResources.

• ☞ Xa roundup and consistency

  This post covers Data sources and XA connections, management of XaResources, and putting all these together.

• ☞ A complete run and a conclusion

  Here I will try to follow a path from the initialization of the db engine and through the begin() of a transaction and creation of a Node to the commit and shutdown.

As I’ve estimated in my first mention of this series on Neo4j internals, Chris ends up giving up writing and starting to hack Neo4j:

Truth been told, I have reached a point where I no longer want to write about Neo but instead I want to start hacking it

Original title and link: Neo4j Transactions and JTA (NoSQL databases © myNoSQL)

Firstly, an interesting presentation by Paulo Gaspar (@paulogaspar7) on ☞ Distributed programming and data consistency

Key take-aways:

• The network falacies:

  1. The network is reliable
  2. Latency is zero
  3. Bandwith is infinite
  4. The network is secure
  5. Topology doesn’t change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogenous

• CAP Trade-offs:

  • CA without P: Databases providing distributed transactions can only do it while their network is up
  • CP without A: While there is a partition, transactions to an ACID db may be blocked until the partition heals
  • AP without C: Caching provides client-server partition resilience by replicating data, even if the partition prevents verifying if a replica is fresh

Another interesting post on this topic, is ☞ The CAP Theorem Distilled by Sid Anand (@r39132). Under the assumption that “any system needs to support ‘P’” (nb I am not sure why the article is limiting the analysis to this case only), the article compares ‘A’ vs ‘C’ in CAP:

If you choose ‘C’, your system might implement 2-phase commit (a.k.a 2PC) . […]

On the other hand, if you opt for an AP system, you are opening the door to potential data inconsistencies. […] AP systems can get quite complicated (relative to CP systems)

In two subsequent articles, Sid is explaining “eventual consistency” for ☞ non-techies and for ☞ techies . I liked the way Paulo visually represented inconsistency across time in his slides: