Over a million developers have joined DZone.

Maintaining Transaction Boundary Integrity in a Distributed Cluster

DZone 's Guide to

Maintaining Transaction Boundary Integrity in a Distributed Cluster

This gives you transaction boundaries on a distributed database and allows you to reason about your data in a saner fashion.

· Database Zone ·
Free Resource

We pretty much treat RavenDB’s transactional nature as a baseline — same as the safe assumption that any employee we hire will have a pulse. (Sorry, we discriminate against Zombies and Vampires because they create a hostile work environment. See here for details.)

OK, now back to transactions, and why I’m bringing up a basic requirement like that. Consider a case when you need to pay someone. That operation is composed of two distinct operations. First, the bank debits your account and then the bank credits the other account. You generally want these to happen as a transactional unit — either both of them happened or neither of them did. In practice, that isn’t how banks work at all, but that is the simplest way to explain transactions, so we’ll go with that.

With RavenDB, that is how it has always worked. You can save multiple documents in a single transaction, and we guarantee that we are either able to save all of them or none. There is a problem, however, when we start talking about distributed clusters. When you save data to RavenDB, it goes into a single node and then it is replicated from there. In RavenDB 4.0, we are now guaranteeing that replicating the data between nodes will also respect the transaction boundary, so overall, in the cluster, you can now rely on the fact that we’ll never break apart transactions.

Let's consider the following transfer:

  • Deduct $5 from accounts/1234
  • Credit $5 to accounts/4321

These changes will also be replicated as a single unit, so the total amount of money in the system remains the same.

But a more complex set of operation can be:

  • Deduct $5 from accounts/1234
  • Credit $5 to accounts/4321
  • Deduct $5 from accounts/1234
  • Credit $5 to accounts/5678

In this case, we have a document that is involved in multiple transactions. When we need to replicate to another node, we’ll replicate the current state. And we do that in batches. So it's possible that we’ll replicate just:

  • Credit $5 to accounts/4321

We don’t replicate accounts/1234 yet because it has changed in a later transaction. That means that on one server, we suddenly, magically have more money. While in general, that would be a good thing, I’m told that certain parties aren’t in favor of such things, so we have another feature that interacts with this. You can enable document revisions — in which case even if you documents are modified multiple times with different transactions, we’ll always send the transactions across the wire as they were saved.

This gives you transaction boundaries on a distributed database and allows you to reason about your data in a saner fashion.

database ,distributed database ,clusters ,transaction management

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}