Data access and transactions

WebSphere® eXtreme Scale uses transactions. After an application has a connection to a data grid, you can access and interact with data in the data grid.

Transactions in Java applications

With Java™ applications, you can establish a client connection to a distributed instance or create a local instance.

When an application interacts with a Session, it must be in the context of a transaction. A transaction is begun and committed or rolled back using the Session.begin, Session.commit, and Session.rollback methods on the Session object. Applications can also work in auto-commit mode, where the Session automatically begins and commits a transaction whenever the application interacts with Maps. However, the auto-commit mode is slower.

A thread in a Java application needs its own Session. When you want your application to use the ObjectGrid on a thread, call one of the getSession methods to obtain a Session. After the application is finished with the Session, call the Session.close() method. This method closes the session, returning it to the pool and releasing its resources. Closing a session is optional, but improves the performance of subsequent calls to the getSession() method. If the application is using a dependency injection framework such as Spring, you can inject a Session into an application bean when necessary.

After you obtain a Session, the application can access data stored in maps in the ObjectGrid. If the ObjectGrid uses entities, you can use the EntityManager API, which you can obtain with the Session.getEntityManager method. Because it is closer to Java specifications, the EntityManager interface is simpler than the map-based API. However, the EntityManager API carries a performance overhead because it tracks changes in objects. The map-based API is obtained by using the Session.getMap method.

Transactions in .NET applications

In .NET applications, each thread must have a separate IGridMapPessimisticTx or IGridMapPessimisticAutoTx object. With the IGridMapPessimisticTx object, you use the Transaction property to explicitly begin, commit or rollback the transaction. With the IGridMapPessimisticAutoTx object, the transaction begin, commit and rollback operations occur automatically. After you obtain one of these objects, the application can access stored data in the data grid.

The logic of using transactions

Transactions may seem to be slow. You must use transactions for the following reasons:

To allow rollback of changes if an exception occurs or business logic needs to undo state changes.
To hold locks on data and release locks within the lifetime of a transaction, allowing a set of changes to be made atomically, that is, all changes or no changes to data.
To produce an atomic unit of replication.
To update multiple partitions.

You can customize how much transaction support is needed. Your application can turn off rollback support and locking but at a cost to the application. The application must handle the lack of these features. Examples of how the application can manage transaction support follow:

An application can turn off locking by configuring the BackingMap locking strategy to be NONE. This strategy is fast, but concurrent transactions can now modify the same data with no protection from each other. The application is responsible for all locking and data consistency when NONE is used. This option is not valid for WebSphere eXtreme Scale Client for .NET applications, which support the PESSIMISTIC locking strategy only.
An application can change the way objects are copied when accessed by the transaction. The application can specify how objects are copied with the ObjectMap.setCopyMode method. With this method, you can turn off CopyMode. Turning off CopyMode is normally used for read-only transactions if different values can be returned for the same object within a transaction. Different values can be returned for the same object within a transaction.

For example, if the transaction called the ObjectMap.get (Java) or IGridMapPessimisticTx.Get (.NET) method for the object at T1, it got the value at that point in time. If it calls the get method again within that transaction at a later time T2, another thread might have changed the value. Because the value was changed by another thread, the application sees a different value.

[Java programming language only] If the application modifies an object retrieved using a NONE CopyMode value, it is changing the committed copy of that object directly. Rolling back the transaction has no meaning in this mode. You are changing the only copy in the ObjectGrid. Although using the NONE CopyMode is fast, be aware of its consequences. An application that uses a NONE CopyMode must never roll back the transaction. If the application rolls back the transaction, the indexes are not updated with the changes and the changes are not replicated if replication is turned on.

The default values are easy to use and less prone to errors. If you start trading performance in exchange for less reliable data, the application needs to be aware of what it is doing to avoid unintended problems.

CAUTION:

Be careful when you are changing either the locking or the CopyMode values. If you change the values, unpredictable application behavior occurs.

Transactions and partitions

[Java programming language only] Transactions in Java applications can update a single or multiple partitions, however updating a single partition is the default behavior. [Version 8.6 and later] [.net programming language only] .NET applications can only update a single partition.

Use the TxCommitProtocol Session API to enable multi-partition transaction support for WebSphere eXtreme Scale in a stand-alone environment. You can use the following two options:

TxCommitProtocol.ONEPHASE (default): Transactions from a client can read from multiple partitions, but can update one partition only. Attempts made to update multiple partitions fail.
TxCommitProtocol.TWOPHASE: Transaction from a client can read and update multiple partitions. The transaction uses the two-phase commit protocol to ensure data written to the partitions are automatically committed or rolled back. If the transaction only writes to a single partition then a one-phase commitment protocol is used.

You need to enable and configure eXtremeIO before configuring multi-transactions with WebSphere eXtreme Scale. For more information, see Configuring IBM eXtremeIO (XIO).

Queries and partitions

If a transaction has already searched for an Entity, the transaction is associated with the partition for that Entity. Any queries that run on a transaction that is associated with an Entity are routed to the associated partition.

If a query is run on a transaction before it is associated with a partition, you must set the partition ID to use for the query. The partition ID is an integer value. The query is then routed to that partition. This only applies if the transaction is configured to use a one-phase commitment protocol.

Queries only search within a single partition. However, if the session is set using a two-phase commitment protocol, then set the partition ID for the query to -1. This fetches results from all partitions. You can use the DataGrid APIs to run the same query in parallel on all partitions or a subset of partitions. Use the DataGrid APIs to find an entry that might be in any partition.