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

What's New?

The following changes have been made since the Coherence Common 1.1.1 release to produce this release.

• Removed the MemberAware interface as it was inefficient in it's implementation when used in large
  clusters and may return incorrect Recovery statuses when after n+1 failovers / partition load balancing cycles. It was
  only useful for simple demonstrations (and not in other Incubator projects)

• Refactored the AbstractMultiplexingBackingMapListener to remove dependency on MemberAware. Introduced the concept of a PartitionManagement Cause to replace LoadBalancing and Recovery causes.

• Modified the ThreadFactories.newThreadFactory(...) method to support naming newly created threads and the specification of an owning ThreadGroup. This helps eliminate warnings about "calling a CacheFactory on a Service Thread".

• Now correctly displays Ticket.NONE when using Ticket.toString()

• Added the TicketBook.iterate( n ) method to support iterating over the first "n" Ticket s in a TicketBook
  (without removing them)

• Added the TicketBook.consume( n ) method to support removing (ie: consuming) the first "n" Ticket s from
  a TicketBook (without having create an iterator over them).

• Added a logging package (and Logger) to simplify using Coherence-based Logging in other Incubator projects.

• Added a "deploy" target to the build.xml to simplify deployment to a repository (when not using Maven)

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.