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. In Java™ applications, the difference map tracks all changes for operations such as insert, update, get, and remove. 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.
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.
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.
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.
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.
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.
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.