Apache Geode CHANGELOG

Comparing Transactional and Non-Transactional Operations

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

  • Transactional operations affect the transactional view
  • Non-transactional operations do not affect the transactional view

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 operations. Otherwise, you use the same methods as usual. Most methods that run within a transaction affect the transactional view, and they 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 operations.

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 invoked within a transaction, have no effect on the transactional view, but they 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 type UnsupportedOperationInTransactionException.

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

Cache 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 State Write Conflict
create createRegionFactory().create() 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.