The practices of the distributed transactions are far behind its theory. Only one of the approaches to the distributed transactions (2PC) has a large variety of libraries and frameworks to choose from; while the others you need to implement them on you own. Unfortunately 2PC is also the least advanced algorithm so choosing it you sacrifice partition tolerance and performance for the convenience and speed of the development.

Let's take a look of the other major algorithms in the area of the distributed transactions. All of them allow you to do transactions which span for multiple data sources.

Two-phase commit algorithm (2PC)

2PC is the most developed algorithm. It's the heart of the X/Open XA standard which models a generic 2PC-based distributed transaction processing and formalizes the interaction between clients, a coordinator and resources. XA allows vendors do not integrate their solution with all the other solutions but just follow the standard and get the integration for free. JTA is a Java interface to the X/Open XA model.

Some problems of 2PC comes from the fact that the coordinator is a single point of failure. If it is down then the system is unavailable, if there is a network partitioning and the coordinator happens to be in other partition than clients and resources then the system is also unavailable.

Another problem of the algorithm is its blocking nature: once a resource has sent an agreement message to the coordinator, it will block until a commit or rollback is received. As a result the system can't use all the potential of the hardware it uses.

Percolator's transactions

Percolator's transactions are distributed serializable optimistic transactions. They were introduced in the Large-scale Incremental Processing Using Distributed Transactions and Notifications paper by Google and later were implemented in the Amazon's Transaction Library for DynamoDB and in the CockroachDB database.

Unlike 2PC Percolator's transactions:

don't require coordinator so they work when there is a network partitioning and a client executing a transaction and the resources affected by the transaction happen to be in the same partition
use technique similar to the lock-free algorithms so they are non-blocking and better utilize hardware of the cluster

It's very handy that Percolator's transactions can be implemented on the client side. The only requirement is that the datasources must be linearizable and provide compare-and-set operation. The downside is that in the case of race the concurrent transactions can abort each other.

You can take a look on the Visualization of the Percolator's transaction to understand how they work.

RAMP transactions

RAMP transactions are Read Committed isolation level distributed transaction. They were introduced in the Scalable Atomic Visibility with RAMP Transactions paper by Peter Bailis. They are pretty new so they didn't get into any database yet but there are rumors that Cassandra may support them. Also Facebook reported that they are working on the Apollo database which uses Paxos for replication and CRDT & RAMP for cross shard transactions.

As well as 2PC, RAMP transactions require coordinator-like servers but unlike them there can be any number of such servers so there is no availability impact.

Just like the Percolator's transactions RAMP uses non-blocking approach and the relaxed isolation level helps it avoid the contention issues and achieve incredible performance see the paper for the details.

RAMP also has the same requirements to the storages as Percolator's transactions: linearizability and compare-and-set operations.

You can take a look on the Visualization of the RAMP transaction to understand how they work.