The data is not transactionally managed within the region; merely it is
transactionally-managed in relation to its association with a particular
org..
| Modifier and Type | Field and Description |
|---|---|
| protected final CacheDataDescription |
| Access | Constructor and Description |
|---|---|
| protected | BaseTransactionalDataRegionAdapter(Cache underlyingCache, Settings settings, CacheDataDescription metadata)
Deprecated
as a consequence of
Cache being deprecated.
|
| Modifier and Type | Method and Description |
|---|---|
| public CacheDataDescription | |
| public boolean | isTransactionAware()
Implements org. |
| metadata | back to summary |
|---|---|
| protected final CacheDataDescription metadata | |
| BaseTransactionalDataRegionAdapter | back to summary |
|---|---|
| protected BaseTransactionalDataRegionAdapter(Cache underlyingCache, Settings settings, CacheDataDescription metadata)
Deprecated as a consequence of | |
| getCacheDataDescription | back to summary |
|---|---|
| public CacheDataDescription getCacheDataDescription() Implements org. | |
| isTransactionAware | back to summary |
|---|---|
| public boolean isTransactionAware() Implements org. Doc from org. Is the underlying cache implementation aware of (and "participating in") ongoing JTA transactions? Regions which report that they are transaction-aware are considered "synchronous", in that we assume we can immediately (i.e. synchronously) write the changes to the cache and that the cache will properly manage application of the written changes within the bounds of ongoing JTA transactions. Conversely, regions reporting false are considered "asynchronous", where it is assumed that changes must be manually delayed by Hibernate until we are certain that the current transaction is successful (i.e. maintaining READ_COMMITTED isolation).
| |