Transactions

Transactions have many advantages for data storage and manipulation. You can use transactions to protect the data grid from concurrent changes, to apply multiple changes as a concurrent unit, to replicate data, and to implement a lifecycle for locks on changes.

When a transaction starts, WebSphere® eXtreme Scale allocates a special difference map to hold the current changes or copies of key and value pairs that the transaction uses. Typically, when a key and value pair is accessed, the value is copied before the application receives the value. [Java programming language only] In Java™ applications, the difference map tracks all changes for operations such as insert, update, get, and remove. [Version 8.6 and later] [.net programming language only] In .NET applications, the difference map tracks changes in add, replace, get, and remove operations. Keys are not copied because they are assumed to be immutable. If a transaction is rolled back, then the difference map information is discarded, and locks on entries are released. When a transaction commits, the changes are applied to the maps and locks are released.

[Java programming language only] If an ObjectTransformer object is specified in a Java application, then this object is used for copying the value. If the transaction is using optimistic locking, then before images of the values are also tracked for comparison when the transaction commits.

[Java programming language only] If optimistic locking is being used in a Java application, then eXtreme Scale compares the before image versions of the values with the values that are in the map. These values must match for the transaction to commit. This comparison enables a multiple version locking scheme, but at a cost of two copies being made when the transaction accesses the entry. All values are copied again and the new copy is stored in the map. WebSphere eXtreme Scale performs this copy to protect itself against the application changing the application reference to the value after a commit.

You can avoid using several copies of the information. The application can save a copy by using pessimistic locking instead of optimistic locking as the cost of limiting concurrency. The copy of the value at commit time can also be avoided if the application agrees not to change a value after a commit.

Note: .NET applications support pessimistic locking only.

Advantages of transactions

Use transactions for the following reasons:

By using transactions, you can:

Roll back changes if an exception occurs or business logic needs to undo state changes.
To apply multiple changes as an atomic unit at commit time.
Hold and release locks on data to apply multiple changes as an atomic unit at commit time.
Protect a thread from concurrent changes.
Implement a lifecycle for locks on changes.
Produce an atomic unit of replication.

Transaction size

Larger transactions are more efficient, especially for replication. However, larger transactions can adversely affect concurrency because the locks on entries are held for a longer time. If you use larger transactions, you can increase replication performance. This performance increase is important when you are pre-loading a Map. Experiment with different batch sizes to determine what works best for your scenario.

Larger transactions also help with loaders. If a loader is being used that can run SQL batching, then significant performance gains are possible depending on the transaction and significant load reductions on the database side. This performance gain depends on the Loader implementation.

Automatic commit mode

[Java programming language only] If no transaction is actively started, then when an application interacts with an ObjectMap object, an automatic begin and commit operation is done on behalf of the application. This automatic begin and commit operation works, but prevents rollback and locking from working effectively. Synchronous replication speed is impacted because of the very small transaction size. If you are using an entity manager application, then do not use automatic commit mode because objects that are looked up with the EntityManager.find method immediately become unmanaged on the method return and become unusable.

[Version 8.6 and later] [.net programming language only] In .NET applications, the GridMapPessimisticAutoTx map interface provides the equivalent automatic begin and commit operations. The limitations are the same: rollback and locking do not work correctly and synchronous replication speed is reduced.

External transaction coordinators

Typically, transactions begin with the session.begin method and end with the session.commit method. However, when eXtreme Scale is embedded, the transactions might be started and ended by an external transaction coordinator. If you are using an external transaction coordinator, you do not need to call the session.begin method and end with the session.commit method. If you are using WebSphere Application Server, you can use the WebSphereTranscationCallback plug-in.

Java EE transaction integration

eXtreme Scale includes a Java Connector Architecture (JCA) 1.5 compliant resource adapter that supports both client connections to a remote data grid and local transaction management. Java Platform, Enterprise Edition (Java EE) applications such as servlets, JavaServer Pages (JSP) files and Enterprise JavaBeans (EJB) components can demarcate eXtreme Scale transactions using the standard javax.resource.cci.LocalTransaction interface or the eXtreme Scale session interface.

When the running in WebSphere Application Server with last participant support enabled in the application, you can enlist the eXtreme Scale transaction in a global transaction with other two-phase commit transactional resources.