This documentation applies to the Coherence Common 1.3.0. The latest Coherence Common documentation is available here.

What's New?

The following changes have been made since Coherence Common 1.2.0.

• Migrated to use Apache Ivy for dependency management, building and publishing artifacts

• Added the Range.size() method support to determine how many values are in a Range

• Made the AbstractMultiplexingBackingMapListener MapEvent deserialization of Entries lazy (ie: on demand). This improves performance of some AbstractMultiplexingBackingMapListener implementations by as much as 15% (in lab tests)

• Added a getString() to the StringBasedIdentifier

• Added a getUUID() method to the UUIDBasedIdentifier

• Introduced support for Tuples in the com.oracle.coherence.common.tuples package. They are handy for returning multiple type-safe values from methods and Entry Processors.

• Introduced support for Leases in the com.oracle.coherence.common.leasing package. At the moment these are predominantly used by the Messaging layer, but will be handy elsewhere.

• Introduced the MultiplexingBackingMapListener interface.

• Refactored the Cause enumeration out of the AbstractMultiplexingBackingMapListener implementation.
  NOTE: This will break previous code that relied on the Cause enumeration being in the AbstractMultiiplexingBackingMapListener class.

• Introduced the DelegatingMultiplexingBackingMapListener implementation to delegate BackingMapListener
  events to objects in the cache that implement the LifecycleAwareCacheEntry interface. This allows an object to be notified of events happening to itself.

• Introduced the concept of a ContiguousRange based on the previous Range class implementation.

• Refactored the Range class to become an interface. Added several methods to support working with ranges, such as union and size.
  NOTE: This will break previous code that relied on the Range class (which is now an interface). Please use the Ranges class to create ranges from now on.

• Introduced the concept of a SparseRange to represent ordered non-overlapping collections of ContiguousRanges.

The AdvancedConfigurableCacheFactory

The com.oracle.coherence.common.configuration.AdvancedConfigurableCacheFactory is a drop in replacement for the standard DefaultConfigurableCacheFactory that Coherence uses to load and process cache-config.xml files.

While it's completely backwards compatible with the standard DefaultConfigurableCacheFactory, it also adds some advanced functionality to the loading and processing of cache-config.xml, like the ability to introduce and override other cache-config.xml files.

If you've ever wanted to break-up a large cache-config.xml file into separate files, say for different parts or components of an application, the AdvancedConfigurableCacheFactory is your solution.

For Example;

<cache-config>
    <introduce-cache-config file="some-other-config-file-a.xml" />
    <introduce-cache-config file="some-other-config-file-b.xml" />
</cache-config>

Order of <introduce-cache-config... /> declaration is important! Care must be taken when introducing cache config files each introduction will override and replace any equivalently named (or identifiable) xml elements from previously introduced cache config files (in the order in which they are declared and processed).

In the example above, named elements in the "some-other-config-file-b.xml" will override any xml elements with the same name (or identities) that where introduced in "some-other-config-file-a.xml". Additionally, the outer-level config file "my-cache-config.xml" may also override any or all of the "introduced" named elements declared in the "some-other-config-file-a.xml" and "some-other-config-file-b.xml" files.

Nested (recursive) Introductions Nesting introductions are also supported. Thus it is possible to define a cache config file that introduces another cache config, that in turn introduces another cache config and so on. Additionally, graphs of introductions are also supported. That is, the following introductions are valid; A introduces B and C. B introduces D. C introduces D. D introduces E.

Frequently Asked Questions

Why isn't it called <include ... />? like it is in POF configuration files?

The <include ... /> element, as commonly used in POF configuration files, is a textual include (similar to #include in C or C++). The semantics of <introduce-cache-config ... /> are closer to that of <scheme-ref .../> but work on an entire file basis. The <introduce-cache-config ... /> is like "inheritance" but allows further overriding of "inherited" xml elements.