---
title: Comparing Transactional and Non-Transactional Operations
---

<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->


Between the begin operation and the commit or rollback operation are a series of ordinary <%=vars.product_name%> operations. When they are launched from within a transaction, the <%=vars.product_name%> 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](#transactional_operations)**

-   **[Non-Transactional Operations](#non_transactional_operations)**

-   **[Entry Operations](#entry_operations)**

-   **[Region Operations](#region_operations)**

-   **[Cache Operations](#cache_operations)**

-   **[No-Ops](#no-ops)**

## <a id="transactional_operations" class="no-quick-link"></a>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.

## <a id="non_transactional_operations" class="no-quick-link"></a>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`.

## <a id="entry_operations" class="no-quick-link"></a>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 `EntryNotFoundException`or the entry is already invalid |

## <a id="region_operations" class="no-quick-link"></a>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             |

## <a id="cache_operations" class="no-quick-link"></a>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            |

## <a id="no-ops" class="no-quick-link"></a>No-Ops

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.


