• Client View – The client view represents a virtual layer that provides access to the underlying partitioned data. Access to this tier is provided using the NamedCache interface. In this layer you can also create synthetic data structures such as NearCache or ContinuousQueryCache.

• Storage Manager – The storage manager is the server-side tier that is responsible for processing cache-related requests from the client tier. It manages the data structures that hold the actual cache data (primary and backup copies) and information about locks, event listeners, map triggers, and so on.

• Backing Map – The Backing Map is the server-side data structure that holds actual data.

Coherence allows users to configure out-of-the-box and custom backing map implementations. The only constraint for a Map implementation is the understanding that the Storage Manager provides all keys and values in internal (Binary) format. To deal with conversions of that internal data to and from an Object format, the Storage Manager can supply Backing Map implementations with a BackingMapManagerContext reference.

Figure 14-1 shows a conceptual view of backing maps.

Figure 14-1 Backing Map Storage

Description of "Figure 14-1 Backing Map Storage"

Coherence supports the following local storage implementations:

• Safe HashMap: This is the default lossless implementation. A lossless implementation is one, like the Java Hashtable class, that is neither size-limited nor auto-expiring. In other words, it is an implementation that never evicts ("loses") cache items on its own. This particular HashMap implementation is optimized for extremely high thread-level concurrency. For the default implementation, use class com.tangosol.util.SafeHashMap; when an implementation is required that provides cache events, use com.tangosol.util.ObservableHashMap. These implementations are thread-safe.

• Local Cache: This is the default size-limiting and auto-expiring implementation. See Capacity Planning. A local cache limits the size of the cache and automatically expires cache items after a certain period. For the default implementation, use com.tangosol.net.cache.LocalCache; this implementation is thread safe and supports cache events, com.tangosol.net.CacheLoader, CacheStore and configurable/pluggable eviction policies.

• Read/Write Backing Map: This is the default backing map implementation for caches that load from a backing store (such as a database) on a cache miss. It can be configured as a read-only cache (consumer model) or as either a write-through or a write-behind cache (for the consumer/producer model). The write-through and write-behind modes are intended only for use with the distributed cache service. If used with a near cache and the near cache must be kept synchronous with the distributed cache, it is possible to combine the use of this backing map with a Seppuku-based near cache (for near cache invalidation purposes). For the default implementation, use class com.tangosol.net.cache.ReadWriteBackingMap.

• Binary Map (Java NIO): This is a backing map implementation that can store its information outside of the Java heap in memory-mapped files, which means that it does not affect the Java heap size and the related JVM garbage-collection performance that can be responsible for application pauses. This implementation is also available for distributed cache backups, which is particularly useful for read-mostly and read-only caches that require backup for high availability purposes, because it means that the backup does not affect the Java heap size yet it is immediately available in case of failover.

• Serialization Map: This is a backing map implementation that translates its data to a form that can be stored on disk, referred to as a serialized form. It requires a separate com.tangosol.io.BinaryStore object into which it stores the serialized form of the data. Serialization Map supports any custom implementation of BinaryStore. For the default implementation of Serialization Map, use com.tangosol.net.cache.SerializationMap.

• Serialization Cache: This is an extension of the SerializationMap that supports an LRU eviction policy. For example, a serialization cache can limit the size of disk files. For the default implementation of Serialization Cache, use com.tangosol.net.cache.SerializationCache.

• Journal: This is a backing map implementation that stores data to either RAM, disk, or both RAM and disk. Journaling use the com.tangosol.io.journal.JournalBinaryStore class. See Using the Elastic Data Feature to Store Data.

• Overflow Map: An overflow map does not actually provide storage, but it deserves mention in this section because it can combine two local storage implementations so that when the first one fills up, it overflows into the second. For the default implementation of OverflowMap, use com.tangosol.net.cache.OverflowMap.

• Custom Map: This is a backing map implementation that conforms to the java.util.Map interface.

  For example:

  <backing-map-scheme>
     <class-scheme>
        <class-name>com.tangosol.util.SafeHashMap</class-name>
     </class-scheme>
  </backing-map-scheme>

  Note:

  Irrespective of the backing map implementation you use, the map must be thread safe.

• Natural access and update operations caused by the application usage. For example, NamedCache.get() call naturally causes a Map.get() call on a corresponding Backing Map; the NamedCache.invoke() call may cause a sequence of Map.get() followed by the Map.put(); the NamedCache.keySet(filter) call may cause an Map.entrySet().iterator() loop, and so on.

• Remove operations caused by the time-based expiry or the size-based eviction. For example, a NamedCache.get() or NamedCache.size() call from the client tier could cause a Map.remove() call due to an entry expiry timeout; or NamedCache.put() call causing some Map.remove() calls (for different keys) caused by the total amount data in a backing map reaching the configured high water-mark value.

• Insert operations caused by a CacheStore.load() operation (for backing maps configured with read-through or read-ahead features)

• Synthetic access and updates caused by the partition distribution (which in turn could be caused by cluster nodes fail over or fail back). In this case, without any application tier call, some entries could be inserted or removed from the backing map.

The total amount of data held in a Coherence cache equals the sum of data volume in all corresponding backing maps (one per each cluster node that runs the corresponding partitioned cache service in a storage enabled mode).

Consider the following cache configuration excerpts:

<backing-map-scheme>
  <local-scheme/>
</backing-map-scheme>

The backing map above is an instance of com.tangosol.net.cache.LocalCache and does not have any pre-determined size constraints and has to be controlled explicitly. Failure to do so could cause the JVM to go out-of-memory. The following example configures size constraints on the backing map:

<backing-map-scheme>
  <local-scheme>
    <eviction-policy>LRU</eviction-policy>
    <high-units>100M</high-units>
    <unit-calculator>BINARY</unit-calculator>
  </local-scheme>
</backing-map-scheme>

This backing map above is also a com.tangosol.net.cache.LocalCache and has a capacity limit of 100MB. If no unit is specified in <high-units>, the default is byte. See <high-units>. You can also specify a <unit-factor>, as shown in the following example:

<backing-map-scheme>
  <local-scheme>
    <eviction-policy>LRU</eviction-policy>
    <high-units>100</high-units>
    <unit-calculator>BINARY</unit-calculator>
    <unit-factor>1000000</unit-factor>
  </local-scheme>
</backing-map-scheme>

As the total amount of data held by this backing map exceeds that high watermark, some entries are removed from the backing map, bringing the volume down to the low watermark value (<low-units> configuration element, which defaults to 80% of the <high-units>). If the value exceeds Integer.MAX_VALUE, then a unit factor is automatically used and the value for <high-units> and <low-units> are adjusted accordingly. The choice of the removed entries is based on the LRU (Least Recently Used) eviction policy. Other options are LFU (Least Frequently Used) and Hybrid (a combination of LRU and LFU).

The following backing map automatically evicts any entries that have not been updated for more than an hour. Entries that exceed one hour are not returned to a caller and are lazily removed from the cache when the next cache operation is performed or the next scheduled daemon EvictionTask is run. The EvictionTask daemon schedule depends on the cache expiry delay. The minimum interval is 250ms.

<backing-map-scheme>
  <local-scheme>
    <expiry-delay>1h</expiry-delay>
  </local-scheme>
</backing-map-scheme>

A backing map within a distributed scheme also supports sliding expiry. If enabled:

• Read operations extend the expiry of the accessed cache entries. The read operations include get, getAll, invoke and invokeAll without mutating the entries (for example, only entry.getValue in an entry processor).

• Any enlisted entries that are not mutated (for example, from interceptors or triggers) are also expiry extended.

• The backup (for expiry change) is done asynchronously if the operation is read access only. If a mutating operation is involved (for example, an eviction occurred during a put or a putAll operation), then the backup is done synchronously.

To enable sliding expiry, set the <sliding-expiry> element, within a <backing-map-scheme> element to true and ensure that the <expiry-delay> element is set to a value greater than zero. For example,

<distributed-scheme>
   <scheme-name>dist-expiry</scheme-name>
   <service-name>DistributedExpiry</service-name>
   <backing-map-scheme>
      <sliding-expiry>true</sliding-expiry>
      <local-scheme>
         <expiry-delay>3s</expiry-delay>
      </local-scheme>
   </backing-map-scheme>
</distributed-scheme>

Figure 14-2 shows a conceptual view of the conventional backing map implementation.

Figure 14-2 Conventional Backing Map Implementation

Description of "Figure 14-2 Conventional Backing Map Implementation"

A partitioned backing map is a multiplexer of actual Map implementations, each of which contains only entries that belong to the same partition. Partitioned backing maps raise the storage limit (induced by the java.util.Map API) from 2G for a backing map to 2G for each partition. Partitioned backing maps are typically used whenever a solution may reach the 2G backing map limit, which is often possible when using the elastic data feature. See Using the Elastic Data Feature to Store Data.

Figure 14-3 shows a conceptual view of the partitioned backing map implementation.

Figure 14-3 Partitioned Backing Map Implementation

Description of "Figure 14-3 Partitioned Backing Map Implementation"

To configure a partitioned backing map, add a <partitioned> element with a value of true. For example:

<backing-map-scheme>
  <partitioned>true</partitioned>
  <external-scheme>
    <nio-memory-manager>
      <initial-size>1MB</initial-size>
      <maximum-size>50MB</maximum-size>
    </nio-memory-manager>
    <high-units>8192</high-units>
    <unit-calculator>BINARY</unit-calculator>
  </external-scheme>
</backing-map-scheme>

This backing map is an instance of com.tangosol.net.partition.PartitionSplittingBackingMap, with individual partition holding maps being instances of com.tangosol.net.cache.SerializationCache that each store values in the extended (nio) memory. The individual nio buffers have a limit of 50MB, while the backing map as whole has a capacity limit of 8GB (8192*1048576).

Elastic data contains two distinct components: the RAM journal for storing data in-memory and the flash journal for storing data to disk-based devices. These can be combined in different combinations and are typically used for backing maps and backup storage but can also be used with composite caches (for example, a near cache). The RAM journal can work with the flash journal to enable seamless overflow to disk.

Caches that use RAM and flash journals are configured as part of a cache scheme definition within a cache configuration file. Journaling behavior is configured, as required, by using an operational override file to override the out-of-box configuration.

This section includes the following topics:

• Journaling Overview
  
• Defining Journal Schemes
  
• Changing Journaling Behavior
  

Asynchronous backup is typically used to increase client performance. However, applications that use asynchronous backup must handle the possible effects on data integrity. Specifically, cache operations may complete before backup operations complete (successfully or unsuccessfully) and backup operations may complete in any order. Consider using asynchronous backup if an application does not require backups (that is, data can be restored from a system of record if lost) but the application still wants to offer fast recovery in the event of a node failure.

To enable asynchronous backup for a distributed cache, add an <async-backup> element, within a <distributed-scheme> element, that is set to true. For example:

<distributed-scheme>
   ...        
   <async-backup>true</async-backup>
   ...
</distributed-scheme>

To enable asynchronous backup for all instances of the distributed cache service type, override the partitioned cache service's async-backup initialization parameter in an operational override file. For example:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config
   coherence-operational-config.xsd">
   <cluster-config>
      <services>
         <service id="3">
            <init-params>
               <init-param id="27">
                  <param-name>async-backup</param-name>
                  <param-value
                     system-property="coherence.distributed.asyncbackup">
                     false
                  </param-value>
               </init-param>
            </init-params>
         </service>
      </services>
   </cluster-config>
</coherence>

The coherence.distributed.asyncbackup system property is used to enable asynchronous backup for all instances of the distributed cache service type instead of using the operational override file. For example:

-Dcoherence.distributed.asyncbackup=true

This allows writes to not be blocked on latency of writing to the underlying device, however does introduce a potential to lose writes. This mode is primarily viable when data can be replenished and the persisted data provides an optimized means to recover data.

You can enable asynchronous persistence by specifying the <persistence-mode> of the <persistence-environment> as active-async.

There is an out-of-the-box persistence environment that specifies this mode and can be referred to by customer applications by either:

• Specifying the JVM argument:

  -Dcoherence.distributed.persistence.mode=active-async

  Note:

  This is used by all distributed services.
• Referring to the default-active-async persistence environment in the cache configuration:

  See persistence.

  <distributed-scheme>
           ….….….
           <persistence>   
               <environment>default-active-async</environment>
           </persistence>
           ….….….
  </distributed-scheme>
  

  Note:

  This allows you to selectively choose which services have persistence enabled.

You can also define a new <persistence-environment> element in the operational configuration file and specify the mode to be active-async to enable asynchronous persistence. See persistence-environment.

For example:

<persistence-environment id="async-environment">
         <persistence-mode>active-async</persistence-mode>
         <active-directory>/tmp/store-bdb-active</active-directory>   
         <snapshot-directory>/tmp/store-bdb-snapshot</snapshot-directory>
         <trash-directory>/tmp/store-bdb-trash</trash-directory>
</persistence-environment>

To use this environment in the nominated distributed-schemes, it must be referenced in the cache configuration.

For example:

<distributed-scheme>
         ….….….
         <persistence>   
             <environment>async-environment</environment>
         </persistence>
         ….….….
</distributed-scheme>

To ensure that there is no data loss during a controlled shutdown, customers can leverage the service suspend feature. A service is only considered suspended once all data is fully written, including asynchronous persistence tasks, entries in the write-behind queue of a readwrite-backing-map, and so on.

Delta backup uses a compressor that compares two in-memory buffers containing an old and a new value and produces a result (called a delta) that can be applied to the old value to create the new value. Coherence provides standard delta compressors for POF and non-POF formats. Custom compressors can also be created and configured as required.

This section includes the following topics:

• Enabling Delta Backup
  
• Enabling a Custom Delta Backup Compressor