WebSphere® eXtreme Scale Client uses transactions. After an application has a connection to a data grid, you can access and interact with data in the data grid.
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. The map-based API is obtained by using the Session.getMap method.
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:
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.
Transactions in Java applications can update a single or multiple partitions, however updating a single partition is the default behavior. .NET applications can only update a single partition.