Transaction in Hazelcast

Transactions can make life a lot easier since they provide:

• Atomicity. Without atomicity, some of the operations on Hazelcast structures could succeed while other fail, leaving the system in an inconsistent state. 
• Consistency. This moves the state of the system from one valid state to the next. 
• Isolation: The transaction should behave as if it was the only transaction running. Normally, there are all kinds of isolation levels that allow certain anomalies to happen. 
• Durability: This makes sure that if a system crashes after a transaction commits, that nothing gets lost.

0. Transaction in Hazelcast:
1. 
   
2. Hazelcast provides us with transactional capabilities. Offering a REPEATABLE_READ transaction isolation (the only transactional mode currently supported), once you enter a transaction, Hazelcast will automatically acquire the appropriate key locks for each entry that is interacted with; any changes we write will be buffered locally until the transaction is complete. If the transaction was successful and was committed, all the locally buffered changes will be flushed out to the wider cluster, and the locks released. If the transaction was rolled back, we simply release our locks without flushing out the local changes.
3. 
   
4. TransactionContext supports the same basic functionality as the Hazelcast 2.x Transaction, such as begin, commit, and rollback. But it also supports accessing transactional data structures like the TransactionalMap 
   
   In Hazelcast 3, transactions are only available on explicit transactional data structures, such as the TransactionalMap, TransactionalMultiMap, TransactionalQueue and the TransactionalSet.
   It isn’t possible to access a transactional data structure without a transaction. If that happens, an IllegalStateException is thrown.
   
   Currently, Hazelcast provides the following configuration options.
   1. timeoutMillis: Time in milliseconds a transaction will hold a lock. Defaults to 2 minutes. In most cases, this timeout is enough since the transaction should be executed quickly.
   2. TransactionType: Either LOCAL or TWO_PHASE. 
   3. durability: Number of backups for the transaction log, defaults to 1. 
   
   LOCAL: If during the commit phase one or more members crash; the system could be left in an inconsistent state because some of the members might have committed and others might not.
   

   
   TWO_PHASE: Before it commits, it copies the commit log to other members, so in case of member failure, another member can complete the commit.
   

   LOCAL will perform better but TWO_PHASE will provide better consistency in case of failure.
   
   Transactions can also be used from the Hazelcast client. 

  public class TransactionalMember {
     public static void main(String[] args) {
        HazelcastInstance hz = Hazelcast.newHazelcastInstance();
        TransactionOptions txOptions = new TransactionOptions()
             .setTimeout(1, TimeUnit.MINUTES)
             .setTransactionType(TransactionOptions.TransactionType.TWO_PHASE)
             .setDurability(1);
        TransactionContext txCxt = hz.newTransactionContext(txOptions);
        TransactionalMap map = txCxt.getMap("map");
        hz.executeTransaction(txOptions, new TransactionalTask() {
        @Override
        public Object execute(TransactionalTaskContext context)
                                 throws TransactionException {
          map.put("1", "1");
          map.put("2", "2");
        } 
        });
        System.out.println("Finished");
        System.exit(0);
    } 
  }

Hazelcast client: Transactions can also be used from the Hazelcast client.

XA Transaction:

In the X/Open XA architecture, a transaction manager or transaction processing monitor (TP monitor) coordinates the transactions across multiple resources such as databases and message queues. Each resource has its own resource manager. The resource manager typically has its own API for manipulating the resource, for example the JDBC API to work with relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between its own and other resource managers.

Performance:

Transactions can influence the application performance drastically due to locking and dealing with partial failed commits. Try to keep transactions as short as possible so that locks are held for the least amount of time and the least amount of data is locked. Also try to co-locate data in the same partition if possible. 

Reference: