Comparing Transactional and Non-Transactional Operations

Between the begin operation and the commit or rollback operation are a series of ordinary GemFire operations. When they are launched from a transaction, the GemFire operations can be classified into two types:

An operation that acts directly on the cache does not usually act on the transactional view.

Transactional Operations

The CacheTransactionManager methods are the only ones used specifically for cache transactions. Otherwise, you use the same GemFire methods as usual. Most methods that run within a transaction affect the transactional view and do not change the cache until the transaction commits. Methods that behave this way are considered transactional operations. Transactional operations are classified in two ways: whether they modify the transactional view or the cache itself, and whether they create write conflicts with other transactions.

In general, methods that create, destroy, invalidate, update, or read region entries are transactional.

Transactional operations that can cause write conflicts are those that modify an entry, such as put, a load done to satisfy a get operation, create, delete, local delete, invalidate and local invalidate.

Transactional read operations do not cause conflicts directly, but they can modify the transactional view. Read operations look for the entry in the transaction view first and then, if necessary, go to the cache. If the entry is returned by a cache read, it is stored as part of the transactional view. At commit time, the transaction uses the initial snapshot of the entry in the view to discover write conflicts.

Non-Transactional Operations

A few methods, when running in the context of a transaction, have no effect on the transactional view but have an immediate effect on the cache. They are considered non-transactional operations. Often, non-transactional operations are administrative, such as Region.destroy and Region.invalidate. These operations are not supported within a transaction. If you call them, the system throws an exception of this type: UnsupportedOperationInTransactionException(destroyRegion() is not supported while in a transaction.

Entry Operations

Note: Transactional entry operations can be rolled back.
Operations Methods Transactional Write Conflict
create Region.create, put, putAll, Map.put, putAll yes yes
modify Region.put, putAll, Map.put, putAll, Region.Entry.setValue, Map.Entry.setValue yes yes
load Region.get, Map.get yes yes
creation or update using netSearch Region.get, Map.get yes no
destroy: local and distributed Region.localDestroy, destroy, remove, Map.remove yes yes
invalidate: local and distributed Region.localInvalidate, invalidate yes yes
set user attribute Region.Entry.setUserAttribute yes yes
read of a single entry Region.get, getEntry, containsKey, containsValue, containsValueForKey yes no
read of a collection of entries Region.keySet, entrySet, values Becomes transactional when you access the keys or values within the collection. no

Some transactional write operations also do a read before they write, and these can complete a transactional read even when the write fails. The following table of entry operations notes the conditions under which this can happen.

Note: These operations can add a snapshot of an entry to the transaction’s view even when the write operation does not succeed.
Operations Methods Reads Without Writing
create Region.create when it throws an EntryExistsException
destroy: local and distributed

Region.localDestroy, destroy

when it throws an EntryNotFoundException
invalidate: local and distributed

Region.localInvalidate, invalidate

when it throws an EntryNotFoundExceptionor the entry is already invalid

Region Operations

When you create a region in a transaction, any data from the getInitialImage operation goes directly into the cache, rather than waiting for the transaction to commit.

Operations Methods Affected Write Conflict
destroy: local and distributed Region.localDestroyRegion, destroyRegion cache yes
invalidate: local and distributed Region.localInvalidateRegion, invalidateRegion cache yes
clear: local and distributed Region.localClear, clear, Map.clear cache and transaction no
close Region.close cache yes
mutate attribute Region.getAttributesMutator methods cache no
set user attribute Region.setUserAttribute cache no

When you create a region in a transaction, any data from the getInitialImage operation goes directly into the cache, rather than waiting for the transaction to commit.

Operations Methods Affected State Write Conflict
create createRegion committed no
close close committed yes


Any operation that has no effect in a non-transactional context remains a no-op in a transactional context. For example, if you do two localInvalidate operations in a row on the same region, the second localInvalidate is a no-op. No-op operations do not:
  • Cause a listener invocation
  • Cause a distribution message to be sent to other members
  • Cause a change to an entry
  • Cause any conflict

A no-op can do a transactional read.