Skip Headers

# Configuring Unit of Work Cache Isolation at the Descriptor Level

Previous

Next

Use this policy to determine how a unit of work uses a session cache for a specific class. Table: Unit of Work Cache Isolation Options lists the unit of work cache isolation options.

Unit of Work Cache Isolation Options

Option | Description
--- | ---

Using the Session Cache After the Transaction

USE_SESSION_CACHE_AFTER_TRANSACTIONObjects built from new data accessed after a unit of work early transaction are stored in the session cache.

This options is the most efficient as it allows the cache to be used after an early transaction.

Note: Only only use this option if you know that the class has not been modified in the transaction. Otherwise it may load uncommitted data into the session cache.

Isolating New Data After the Transaction

ISOLATE_NEW_DATA_AFTER_TRANSACTION (default) Objects built from new data accessed after a unit of work early transaction are only stored in the unit of work.

This still allows previously cached objects to be accessed in the unit of work after an early transaction, while ensuring that uncommitted data will never be put in the session cache by storing any object built from new data only in the unit of work

Isolating the Cache after the Transaction | ISOLATE_CACHE_AFTER_TRANSACTIONAfter a unit of work early transaction the session cache is no longer used for this class. Objects are directly built from the database data and only stored in the unit of work, even if previously cached. Note: This option my affect performance because you are bypassing the session cache after an early transaction.

Always Isolating the Cache

ISOLATE_CACHE_ALWAYSThe session cache will never be used for the class. Objects are directly built from the database data and only stored in the unit of work. New objects and changes will never be merged into the session cache.

Note: This option my affect performance because you are bypassing the session cache. However if this class is isolated or pessimistic locked and always accessed in a transaction, this can avoid having to build two copies of the object.

Most of these options apply only to a Unit of Work in an early transaction, such as:

- A Unit of Work that was flushed (`write changes`)

- Issued a modify query

- Acquired a pessimistic lock