Video: Distributed ACID Transactions in Apache® Ignite™

My colleague Akmal B. Chaudhri presented a webinar earlier this week where he looked in detail at Apache® Ignite™ architecture's ACID-compliant transactional subsystem. 

After watching his webinar, recorded below, you'll have a better understanding of why companies in many industries, including large banks and financial institutions, trust Apache Ignite and make it their platform of choice.

During the video, Akmal debunks the myth that online financial operations need to be delegated to relational databases due to their ACID (Atomicity, Consistency, Isolation, Durability) transaction support. 

"Today, most of these disk-based relational databases cannot keep pace with the rapidly growing volumes of data that are becoming a bottleneck in the overall transactional system," he said.

There are two paths to deal with this issue: 

  1. Upgrade to more expensive hardware
  2. Migrate to a distributed platform.

Akmal's talk in this video focuses on the following:

  • Data consistency: one-phase and two-phase commit implementations
  • Fault-tolerance: recovery protocol for running transactions
  • Optimistic and Pessimistic transactions
  • Deadlock-free transactions
  • Deadlock detection mechanism

Atomicity Mode

Screenshot from July 19 GridGain webinarIgnite supports 2 modes for cache operations, transactional and atomic. In transactionalmode you are able to group multiple cache operations in a transaction, while atomic mode supports multiple atomic operations, one at a time.

These atomicity modes are defined in CacheAtomicityMode enum:


TRANSACTIONAL mode enables fully ACID-compliant transactions, however, when only atomic semantics are needed, it is recommended that  ATOMIC mode be used for better performance.

ATOMIC mode provides better performance by avoiding transactional locks, while still providing data atomicity and consistency. Another difference in ATOMIC mode is that bulk writes, such as putAll(...)and removeAll(...) methods are no longer executed in one transaction and can partially fail. In case of partial failure, CachePartialUpdateException will be thrown which will contain a list of keys for which the update failed. For more, please visit this page on the website.