We finally managed to get the new Coherence Incubator releases out at the end of last week. Unfortunately I’ve been on the road/in the air so I didn’t get much of a chance to blog about them. As usual each project page contains a high-level overview of the new stuff/updates and changes. For those that want more even more detail, there’s always the history.txt files in the source. However for those that want to know more about the factors/motivations for the changes, here’s a brief commentary.
With increasing adoption of the Incubator Projects in the community we found that some adopters were running into name-clash problems with the cache names we’ve been using. ie: we use a cache called “messages” and so it seems do other people! So one of the major changes in the release was to introduce name-spaces for all of the Incubator cache names. Hence forth all Incubator cache names are prefixed with “coherence.<incubator-project>.<cachename>”.
In addition to this we refactored more of the commonly used code and pushed it down into Coherence Commons. But more about that next.
Coherence Common 1.4.0
Within Coherence Common we made two significant changes. The first involved moving the sequence generation code from the Coherence Command Pattern into Common making it more generally available without needing to depend on Coherence Common. The second change involved “hardening” the Ranges implementation. While the previous Ranges implementation was sufficient for the uses within the Coherence Incubator, after code review we found several things needed to be changed, improved and fixed.
Coherence Command Pattern 2.4.0
Within the Command Pattern we also made two significant changes. The first was an internal refactoring to remove the use of the Invocation Service and instead use EntryProcessors. The motivation for this was mainly to support the use of *Extend clients to submit Commands (and example Extend Cache Configuration is included in the source). The main impact of this change was the internal separation of Commands that are managed as “co-located” v’s those that are “distributed”. That is, there are two caches now to hold Commands, depending on the “management strategy” chosen for the contexts. There are where no changes to the APIs. The second change introduced the notion of a “batch command”. This allows a batch of commands to be submitted atomically. For some use cases this allows for significant performance and throughput improvements.
Coherence Functor Pattern 1.2.0
Apart from the introduction of name-spaces for the Functor Pattern caches, we simply upgraded the project to use the new Command Pattern and Commons releases.
Coherence Messaging Pattern 2.4.0
Apart from the introduction of name-spaces for the Messaging Pattern and the upgrade to use the new Command Pattern/Common projects, the only changes involved resolving two defects and hardening subscription time-outs.
Coherence Push Replication Pattern 2.4.0
Within the Push Replication Pattern we made several enhancements. These included;
a). The ability to support cache-side asynchronous batching of replication to the push replication engine (will provide at least 2x performance improvements)
b). Introduced the FilteringBatchPublisherAdapter that provides the ability to filter out entries before they are pushed to a site (publisher)
c). Introduced the CoalescingBatchPublisherAdapter that provides the ability to coalesce entry operations (ie: coalesce multiple entry updates into a single operation) prior to being pushed to a site (publisher).
d). Fixing the spelling mistake in the DefaultPushReplicationManager class name! (oops).
Having just finished the planning for the next round of releases (and new patterns), I’m really looking forward to what’s next. We should get the roadmap for everyone to see in the next week.