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 Client 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. 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 WebSphere eXtreme Scale Client 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 Client 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.
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.
When the running in WebSphere Application Server with last participant support enabled in the application, you can enlist the WebSphere eXtreme Scale Client transaction in a global transaction with other two-phase commit transactional resources.