Oracle Coherence has very strong capabilities related to data affinity and in-place data processing. Generally, an in-memory data grid is key/value storage with all its limitations, exploiting data affinity, and in-place data processing is a key for building complex solutions (e.g., point-in-time aggregation) without compromising performance.
Performance (in a complex, real-live solution) is another strong advantage of product.
Improvements to My Organization
There were two key challenges which were addressed with a Coherence-based solution. One challenge is input data caching for the risk computation grid – pro-active caching based on Coherence has improved risk calculation time (by reducing data wait time) and allowed the risk grid to scale with yearly growing volumes. Another challenge is intraday risk – point-in-time aggregation based on Coherence reduced delay between data changes and risk updates.
Room for Improvement
Oracle Coherence is mature and feature-rich product. However, there are a few old pain points. One pain point is cluster configuration. On complex projects, it is a challenge to consistently maintain custom Coherence XML and the rest of application configuration (often based on a Spring framework).
Another pain point is testing. Due to internal implementation, it is impossible to start multiple Coherence nodes in a single JVM without special tricks. Multi-node test setup is important if the application is exploiting advanced features of the product. This is somehow addressed by the community (there are three open-source frameworks for testing Coherence), but the problem could have been solved by Oracle once and for all.
Use of Solution
I used it for five years.
Oracle Coherence was used in a few solutions related to intraday and end-of-day financial risk calculation (investment banking).
Oracle Coherence has considerable operational risks. Mistakes in implementation, underestimated volume and load can quickly lead to an instable cluster and drastic degradation of service. Diagnosing and remediating the root cause of cluster degradation is a challenge and requires a lot of product expertise. Nonetheless, well-designed and -sized solutions would normally just work.
Customer Service and Technical Support
Support is very good if major diagnostic work is done by the application team. Bugs and issues are addressed fairly quickly. However, you cannot rely on vendor support for a localized problem in most cases.
I was working and continue to work with alternative in-memory data grid solutions (GemFire in the past, Hazelcast currently). Oracle Coherence has a strong advantage for sophisticated and performance-critical solutions.
It is very easy to get started with Oracle Coherence and run your first local cluster. However, the real learning curve is steep, especially configuring and planning your real cluster. Documentation is extensive but doesn't give you a good learning path.
We have an in-house implementation team. My strong advice is to build internal expertise for Oracle Coherence, in particular due to operational risk. Even after a successful launch of the solution, you might hit problems later (e.g., volume growth, switch to different hardware, Coherence version upgrade) and you'd better have in-house expertise to address them.
Pricing, Setup Cost and Licensing
Oracle Coherence is fairly expensive. There are a number of open-source alternatives offering better value for money, provided you need only the basic features of an in-memory data grid. For high-end solutions, involving advanced features, Coherence outstands competitors, fully justifying its price tag.
Oracle Coherence is very good for a fairly narrow problem area. Building the solution requires investment. The ownership cost might also be considerable. I would recommend making the decision to use Oracle Coherence only with strong technical argumentation and a fair comparison with other alternatives.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Sep 29 2016