Page 1 of 1

2 Phase Commits (XA Protocol)

PostPosted: Wed Apr 11, 2012 2:35 pm
by cloudtran
A lot of people use a 2-phase commit protocol for managing distributed transactions across grid nodes. This can be problematic in terms of performance... in fact, performance can suffer so greatly that you might as well not even use a data grid! CloudTran has its own algorithm for managing distributed transactions that scales and provides full ACID properties. Here's a look at how we do it:

  1. In a grid, you can configure any number of machines to act as transaction managers; could be a few nodes, or every node in the grid. As the grid scales up or scales down, so the transaction managers come and go but the transactions are guaranteed to commit as long as the grid isn't compromised.
  2. At "begin transaction", our API in the app server acquires a transaction ID, and this is used to route to the appropriate transaction manager.
  3. The application changes a particular Object - e.g. Customer#15. This change is reflected in the grid with a transactional entry, which also has the new value and the transaction. If another transaction tries to read this entry, it will get back the old (committed) value. If another transaction tries to change this entry with another transaction, it will get an optimistic locking exception.
  4. If the transactional entry is correctly written, a copy is sent to the manager for this transaction.
  5. When the client commits or rolls back the transaction, this is directed to the transaction manager which
  • gets a correct order for the transaction (to ensure isolation)
  • commits the transaction into the grid AND backs up to a local transaction log
  • returns to the caller - the transaction is free to go, before we start hitting the databases
  • then persists to the databases, using a "native" transaction to each database rather than a distributed transaction to get adequate performance.