CloudTran Home

<< Back Contents  >  3.  Product Concepts and Architecture Forward >>

3.2 Transaction Mechanics

   The programming examples in this section refer to the TopLink Grid version of CloudTran. See The Low-Level API for a cache-level approach to accessing data.   

 3.2.1  Introduction
 3.2.2  Deployment Options
 3.2.3  Transaction LifeCycle
 3.2.4  Reading and Changing Data      Optimistic Locking      Pessimistic Locking
 3.2.5  Transaction Manager Operation
 3.2.6  Database Handling

3.2.1  Introduction
Cloudtran uses a new transaction algorithm that addresses the requirements of multi-machine grids, above and beyond classical transaction managers. These requirements are:
  • aggregate performance
  • scalability
  • persistence (data outside the grid is crucial)
  • handle failover (data in the grid is crucial)
  • no unbounded delays for clients.
In J2EE or J2EE lite, there are two backend tiers: the app servers (running servlets or sessions) and the database. Survival of the database was crucial as the source of data and for application locking etc.

In a grid environment, there are three tiers - with the cache tier in between the app servers and the database. Now it's not just the database that has to survive: the data in the grid is also critical. It introduces a further requirement: the need to keep the cache and data tiers consistent.

This section describes how CloudTran works in a grid environment to provide fast, scalable transaction management.

3.2.2  Deployment Options
In the three tiers we outlined above, CloudTran operates in the cache tier - within the grid itself. This is how it achieves high performance - it uses grid features as part of the cluster.

You can configure any number of machines to act as transaction managers; it 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. Just as for regular data caches, CloudTran transactions are guaranteed to survive a single machine outage, but there must be two transaction managers running to guarantee this.

3.2.3  Transaction LifeCycle
A transaction begins from the client. In the case of CloudTran Coherence, this is the application executes transaction.begin() in TopLink.

The CloudTran client caches a range of transaction ids. It chooses one and uses it to route a "start transaction" request to the CloudTran manager. The manager is deployed as a partitioned service, so the processing load and data is spread evenly across nodes providing the transaction management service.

To complete the transaction, the application executes transaction.commit() or transaction.rollback().

The CloudTran manager is built to handle large transactions, both in the amount of data in the transaction, and the number of managers involved. By passing the CTxDefinition object, any number of data nodes can contribute to the transaction. In other words, this is distributed transactions across processing nodes, without XA. This feature is not currently exposed in the TopLink Grid version but will be supported in the next version via the Low-Level API.

3.2.4  Reading and Changing Data
TopLink Grid provides three modes for working with Coherence, as described here.

In all these modes, the Coherence cache is used as the L2 cache. These modes differ in whether they use the database or the grid as the first port of call for reads and writes.

CloudTran adds the ability to write transactions to the grid quickly and then relay them to the database. This makes transactions quicker to commit - the user gets better response time - and resolves the inconsistencies between the database and the grid that can arise without CloudTran. This means that CloudTran only affects the write side of transactions; the read side is the same as for the standard TopLink Grid modes.

To make this possible, CloudTran requires that all changes to the database tables go through the TopLink Grid application, to avoid update conflicts with other applications.  Optimistic Locking
Optimistic locking is the default mode for TopLink Grid and CloudTran. In this mode, the changes are collected in the application (in the L1 cache) rather than in the grid (holding the L2 cache). When the application commits the transaction, standard TopLink writes the changes to the grid or the database, depending on the mode.

With CloudTran, the changes collected in the client are first sent into the grid. For each object, CloudTran

  1. does the optimistic locking check, that another client hasn't changed the entry since it was read
  2. makes a transactional entry in the cache, which holds both the transactional (dirty) value and the original (committed) value. Other client transactions interact with the transactional entry as follows:
     - a read will get back the old (committed) value
     - a change from another transaction will get an optimistic locking exception
     - an attempted pessimistic lock will get a pessimistic locking exception.  Pessimistic Locking
This applies a transaction lock on the object in the grid, equivalent to a row lock. Unlike the delayed writes in optimistic locking mode, the pessimistic lock is applied immediately and released when the transaction commits or rolls back. This makes it suitable for heavy write applications: an application avoids having its changes aborted because another thread made changes in the meantime.

The application creates the pessimistic lock with entityManager.find( X.class, id, LockModeType.PESSIMISTIC_READ ). This then prevents other applications applying the same pessimistic lock, or overwriting in optimistic locking mode.

3.2.5  Transaction Manager Operation
The happy path is that the client requests the transaction manager to commit the application.
If the client encounters any problems, it will rollback the transaction instead. If the client crashes, the transaction manager will timeout the transaction after the specified delay.
The steps the transaction manager performs to commit the transaction are described in detail in the next section.
3.2.6  Database Handling
The persist to the database is done after the commit to the grid. CloudTran ensures isolation of transactions to the database: order is preserved, so that transactions committed by the managers on different nodes don't get out of order. The ordering is guaranteed by the isolator node.

The transaction manager nodes buffer the information to commit to the databases. If a database is unavailable, the manager continually tries to reestablish the connection and then commits the transaction. In entity grid mode (all data is in the grid), this means the application can operate for some time without writing to the database. The maximum number of transactions per manager is configured in the ct.txb.maxTransactions property.

As the grid operates much faster than databases that use hard disk storage, CloudTran's buffering capability can smooth demand spikes. The user application can commit at high speed to meet the high demand; CloudTran can buffer the data until the databases catch up. If this situation goes on too long, the manager's transaction limit is reached and the client eventually gets delayed.

Another aspect of the database handling is that, when the databases does start to fall behind, the managers batch up transactions to the database into one transaction - which is possible when the data of the transactions does not share any database rows. The amount of batching is controlled by the ct.persist.maxRowsForDataSourceTransaction property. This improves performance because most databases perform better when they commit larger transactions.

Copyright (c) 2008-2013 CloudTran Inc.