Oracle Coherence Reviews

We use 75% of the functionality of the product, including Coherence Incubator (not embedded for our version yet). The most interesting features for us are push replication and write through because these give us a lot of flexibility with data.

From the point of view of push replication, we are able to share data between different projects without attaching original data, so, if any client modified this data by error, it wouldn't affect the rest of the projects.

Regarding the feature of write through, we need to persist to DB a lot of data that changes three times per second. However, this is difficult to support by a database. (We have statistics in Coherence of 120 million puts in the cache.) What we do in this case is write to Coherence and then persist to database in batch mode, so the database receives fewer charges than if the streaming is connected directly.

We are storing information from one of our applications. This allows us to answer requests in milliseconds, while the application would take seconds to answer request from clients.

First of all, extend clusters between different sites. We have done this configuration but is not recommended by Oracle. This configuration is strategic for us.

Oracle doesn't recommend having an extended cluster between two CPD with different locations (in our case, 20 kms apart). The recommended way to implement this is replicating information between the different CPDs. In our case, we have an extended cluster between these two CPDs and we found some issues with, for example, push replication. With an extended cluster between two CPDs, Coherence opens two replication channels, one per site; however, only one site replicates its data. I think this issue is resolved in 12.1.1. with federated caches, but we haven't check this behaviour yet.

I have used it for for years, since 2012.

In four years, we haven´t found any issues with stability. We have had some problems but they derived from how clients use this product.

As mentioned, we have extended clusters between different sites, even though Oracle does not recommend this configuration.

Depending on the consultant, we were very happy or very unhappy, so I would rate technical support 5/10.

I did not previously use a different solution.

Initial setup was complex, until we contracted an expert who helped us to configure everything. After that, life was easier. ;)

Due to the licensing prices, we are looking for other solutions as an alternative to Coherence. It is very expensive and projects are not willing to pay this amount of money for caching data, so they requested that we find a cheaper alternative.

People here were using Ehcache or other solutions, but we decided to use Coherence as our corporate solution.

It is a very powerful tool but is very expensive, so if you don´t have enough money, just choose another solution.

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.

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.

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.

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.

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.

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.

• Coherence Extend with its concept of a proxy instance, thus allowing flexibility even with the Enterprise Edition
• Read- and write-through capability
• A good community maintaining the Coherence Incubator project: Though this isn’t directly from the vendor, the fact that such wonderful documentation exists makes it easier for the users of the product.
• Ease of clustering and the data fabric operation + querying
• Multi-cast free operation

I am unable to name specific projects and companies for confidentiality reasons. I have, however, listed the high-level aspects of how Coherence benefited us.

For company X, a major telecom provider in the continental United States, we had the GRID edition here. A single logical cache scattered across various geographies ensured we had only one cache to look against (location transparency) at the same time, ensuring high availability. With Coherence taking care of CAP (Consistency, Availability and Partition Tolerance) we had little to worry about in those aspects. The ability to add any number of server instances and the ability to query with a simple API reaped benefits in our application scaling and the developers happy with the ease of coding.

In short, features across editions but this is a moot point if it directly relates to room for improvement and is a subjective topic. Better support for active-active data center capability in Enterprise Edition. We could achieve this through a fully replicated cache or having our distributed caches in a single cluster placed across two different centers. The former doesn’t scale for high-write scenarios and is available only in the GRID edition while we used Enterprise edition in our project. The latter will result in direct coupling between two data centers which defeats the purpose of active-active data center availability.

We had to write a custom solution based on listening to events transported between data centers on Kafka infrastructure, but had to go through a lot of trouble to suppress events originating from the same data center to make sure we don’t go into an infinite loop in achieving replication. Easier API support for this purpose would have helped.
Greater tooling support for moving across editions and implementing Coherence Extend would also help.

I have used it for more than two years.

I have not encountered any stability issues.

I have not encountered any scalability issues.

Technical support is 8/10.

I did not previously use a different solution.

Initial setup was complex. We wrote a lot of wrapper code around the Coherence libraries in order to make it easier for the developer.

Be aware of the pitfalls of using Enterprise Edition in a vast enterprise ecosystem. Specifically, keep in mind the long-term needs of the evolution of your organization’s enterprise infrastructure and susceptibility to change of technology. For example, only GRID edition supports replicated caches, local transactions and different types of clients across tech stacks.

Before choosing this product, we looked at Terracotta and other custom caching solutions.

Make sure you understand which edition gives which capability, and how that maps to your current needs and your long-term infrastructure evolution. Build wrapper libraries abstracting your actual caching implementation to make it easier for moving across editions and even vendors in the future.

From a non-functional side:

• - Horizontal scalability
• - High performance
• - Resilience

From a functional side, we use all aspects of the product in multiple applications. Popular features are querying, aggregations, cluster replication and language interoperability.

We use Coherence in a range of applications, from business-critical applications dealing with a vast amount of fast-moving data, to smaller applications looking to share data efficiently internally and with external apps and businesses.

One example would be as a portion of a risk-calculation engine that calculates complex values like PV, VaR and Greeks. Other technologies don’t allow the same level of scale and compute capability, while providing rigorous resilience and security underpinnings.

• Integration with non-Oracle products
• Becoming open source and creating an ecosystem allowing users to contribute features in a controlled manner

I have used it from version 3.3 onwards, a period of about eight years.

We have encountered the occasional minor bug and very occasional more serious bug.

I have not encountered any scalability issues.

Technical support is very good.

I did not previously use a different solution.

We use Coherence for a number of applications, each with different requirements. It’s hard to provide a simple answer regarding initial setup but, in general, we find that Coherence is relatively simple to set up and use. However, it quickly becomes very complex as more features are used.

The product was in use when I joined.

Coherence is the most mature product in this space, with the backing of a large support organization.

For a long period, they led the field and are arguably still leading it, but there are other smaller, newer technologies that are catching up fast.

• Entry processors
• Distributed cache
• Events

It has allowed us to greatly improve our response times in several services by caching part of the database into Coherence and executing complex queries using EntryProcessors.

Configuration is too complex. One of the reasons configuration can be complex in the POF is due to the XML files required for the IDs of the classes. Also, the normal configuration files in XML are not so easy to use; I’m not an expert on them, but I have heard complaints from some of my colleagues.

There is a a lot of room for improvement with POF serialisation. It is slow compared to other serialization mechanisms. We have done some testing using Kryo and custom serialisation built by ourselves, and I have managed to serialise / deserialise 10 times faster than POF. And I haven’t event tried using Unsafe. That means there is even more room for improvement.

POF serialisation also requires both XML files with the IDs of all the Java classes that are going to be stored and implementing the write external read external methods with all the fields of the classes. If you have a few classes, it is fine, but when you try to store complex messages like FIXML or FPML protocols, it becomes quite a nightmare. In our case, we have built a code generator that solves our problem, but is not a simple solution.

Support for writing the cache contents to disk and recover it should be available in production. This feature allows writing the current content of the cache into a file on disk and being able to repopulate the cache later with this information. This is very useful when, for any reason, there is a need to stop all the cache nodes for some time and restart them again without losing information. The problem is that it is not, or at least it was not, supported for production environments. That means we cannot really use it. Our solution was to use a backing database, but that is not trivial, either, because the only way to represent our complex objects into the database was with blob binaries.

I have used it for four years.

We found some issues using the incubator libraries for database integration on writing and also using the feature to write cache contents to disk.

I have not encountered any scalability issues.

Technical support is 5/10; not very good, in Spain at least.

I did not previously use a different solution.

We have recently evaluated other solutions such as Hazelcast and GridGain.

Get a good expert on the technology, because the learning curve can be high.

The features that were of most value to us:

• Uptime
• Scalability
• Speed
• The ability to read-through and write-through to a backing datastore (something that other caches usually require a separate solution for)

An example of how the product improved organizational function was in the speed of request processing. The client had needs to support very high throughput, particularly at certain “peak” times of the year, both in terms of bandwidth for data streaming, as well as retail transactions. A robust standalone caching solution that prioritized speed of data serialization and data integrity was a must. Coherence delivered on that front.

Coherence’s issues (besides high monetary cost compared to other caching solutions) were mostly around the high learning curve required to use it properly, as well as the technical challenge of maintaining a separate artifact of mapped, POF-serializable data types for the cache to have available in its classpath.

In other words, integrating it into an overall solution was not easy from an integration and a code complexity standpoint. This caused developers to either put off integrating it for as long as possible, or otherwise struggle with it more than with something like memcached or ehcache.

I have personally used the solution for approximately one year (it was in use much longer at the organization).

For the most part, we have not encountered stability issues.

Scalability was not an issue.

In this case, Coherence was the incumbent technology.

While Coherence was already deployed on premises, integrating it into a new application was cumbersome.

My understanding is that Coherence is not cheap, based on Oracle’s Technology Global Price List. However, as a contractor, I did not participate in decision-making related to cost.

I have evaluated/used other products since, and have concluded that Coherence offers slightly superior performance and integrated read/write-through at the cost of technical complexity. Complexity being a huge contributor to risk/cost for projects, I am more likely to use other products as a result.

My advice to those looking to implement Coherence is to hire someone who has used it extensively in the past, and to create sufficient documentation internally to bring developers up to speed with how to integrate it into their applications. The learning curve to get comfortable with the configuration/deployment/mapping was the single biggest pain point for our project, and greater than I would expect of a third-party integration like this.

Coherence allows linear on-line scalability across multiple commodity servers. It’s a very important feature for SaaS providers, as it allows adding and removing resources on demand and without taking your production system down. High availability is a key for financial business continuity, and by distributing clusters across multiple Amazon Availability Zones – while still maintaining very good latency - Coherence is able to sustain hardware or even AZ failure without any interruption on the application side, given that cluster architecture is designed correctly.

We implement ticketing analytics using Coherence.

Coherence lacks decent visual management and monitoring tools. The free solution offered (JConsol) is not very superb in quality, and is not designed for use in a web-based, SaaS environment.

Also, some information on the website is outdated and does not reflect the latest functionality or syntax.

We would like to have comprehensive, native, reliable, out-of-box replication between clusters; we have a DR center on the west coast and we would like to replicate data there, ideally in three clicks, without changing a lot of settings or extensive setup and development.

I used the solution for six months.

I have not encountered any stability issues.

We have not encountered any scalability issues on the cluster side, but we have seen problems with big messages on the .NET client.

Technical support is 3 or even 2 out of 10. Working directly through an account rep or a contact on Coherence dev team helps a lot.

I did not previously use a different solution.

Before choosing this product, we evaluated GridGain and Hazelcast.

Get a cheaper price and consider your code stack – it fits best with Java-based companies.

While you can have a successful career with Coherence just being a get/set man, its true power is realized when you leverage the full scale of the cluster as a whole and exploit its distributed processing capabilities.

For the use cases I’ve implemented, the features I used most frequently and have gone head-to-head with incumbents are as follows:

• InvocationService - I have to admit that I took this for granted up until I went against IBM’s eXtreme Scale. Most organizations want to preload/warm the cache and the InvocationService allows you to issue commands to each member in a distributed manner. Parallelizing this activity gains economies of scale since the load time and rebalancing can be kept to a minimum. Said another way, a million rows can be loaded in the time it takes to load 100,000 if you have 10 storage enabled members. Each member is issued a command which details what rows it is responsible for loading. Coherence provides a number of the libraries required to handle this including ‘retry’ functionality hooks and abstracts all the threading/concurrency logic which would be a nightmare to sort out; as IBM learned on this project. This is in direct contrast to extremeScale’s capability - which relied on leveraging Java’s Executor classes. Basically, they had to roll their own distributed processing engine while on-site.
• Filter, Aggregators and EntryProcessors - Before MapReduce & Hadoop came on the scene in such force Coherence had equivalent functionality that was much easier to use. Filters provide the ability to use conditional boolean logic against your data Out-Of-the-Box. Many fail to realize how powerful this is. In the bake off extremeScale had nothing close to this and therefore had to code it. The requirement was to port a StoredProcedure’s logic, which took 30+ secs to run, into something the grid can run. The implementation was based on an EntryProcessor that leveraged Filters and Aggregators. While I would love to say it was strategic coding ability, it wasn’t - I merely used OOB tools. The end result was that the EntryProcessor, running a complex workflow, was a magnitude faster than IBM’s get() call.
• POF - Portable Object Format is the binary optimized proprietary Coherence serialization. It provides staggering Object compaction. For example, an Item object that was 750 bytes with Java serialization is 31 bytes with POF. This has a rippling impact across the entire app, the cluster, even your network since it needs to handle the chatty cluster members.

The biggest improvement is in speed - everything is faster from record retrieval to workflow processing.

Tooling around complex cluster config files so issues can be identified before the cluster is stood up - and subsequently collapses. Cluster management tools that are independent of WebLogic. Dynamic cluster config rollout and rollback. Ideally this would be used in dev as a prod cluster should be locked down. I’d also like to have some sort of GUI (out of the box) that illustrated cluster member vitals; storage, heap, offHeap, watermarks, evictions, etc.

Monitoring and configuration could be easier while support for streaming data windows and the like isn’t available yet. Moreover, native cron(scheduling) capabilities and an Async API would be a nice to have but those challenges can be overcome with 3rd party libraries. Lastly, native security features would alleviate some concerns and workarounds however, I fully understand impact on performance...

I’ve used Coherence since 2008. I transitioned into consulting where I led a number of projects across several organizations to define, install, and integration clusters for maximum impact on critical business systems.

I have only needed an assist from Oracle once and the issue turned out to be a config problem. The organization had a healthy support agreement and Oracle was able to turned it around quick. Perhaps one of the reasons I haven’t engaged them more is because I jumped into the community early on. I attended every Coherence SIG [Special Interest Group] meeting that I could and became friendly with a few of the developers.

Coherence is very easy to get running locally. Standing up, or defining a cluster for that matter is another task entirely. Each cluster has many ‘knobs’ to dial in. While this offers great flexibility, one should exercise caution when getting into areas of the config that are not understood.

The objective of the project and the performance need to be kept in sight. Here are some questions to help drive the configurations files: Is your project read or write heavy? This will dictate if you should have more smaller nodes vs less larger ones. Should they be storage enabled or not? How much data does the app generally use, would a near cache be beneficial? How often is your reference data used, how much is there determines if it should replicated or not. How many members should there be? Do I need to use a prime number somewhere? Why? Do I need eviction policies, what should they be based on? How do I tell if my cluster is too chatty? How will other apps leverage the cluster? Should I use WKA? Will that prevent new members from joining?

It goes on and on and we didn’t touch DR or monitoring.

I’ve done both and in most cases the projects didn’t have proper momentum until a SME was introduced and the questions above could be addressed. Most folks apply relational thinking towards a cluster and that generally doesn't end well. While you can use rich objects, I’d look for a different model - something flat. Or you need to strictly define your cache strategy to keep hierarchies together (hard to do).

A side by side POC was done with IBMs eXtreme Scale on a project. I also have experience with Gemfire - and wish I didn’t.

Take the time to learn it and test all assumptions. For example, I was using push replication [PR] to satisfy a client's disaster recovery [DR] requirement. All of a sudden the primary cluster collapsed - ran out of memory despite having high watermarks configured. As it turned out the DR site connection went down and PR calls started to queue. The high watermark calculation did not know about the PR queue. This was very subtle use case as I didn’t consider what would happen to the PR calls if the other end wasn't available.

As well as using HotCache to synchronise a Coherence cache with database tables in real-time, it can also be used to warm the cache by loading an initial dataset. The nice thing about this approach is that cache warming is just an extension to the setup for cache synchronisation.

The Customer Facing Application response time has been improved 95%. Also, in the releases the Portal does not goes down as the data is being pulled from the Cache not from the Database.

Monitoring API needs to be improved and needs to be user friendly. Also, the error and exception handling is not that great as it can be difficult to debug issues.

We have been using this solution for five years.

The GAR file naming convention.

There have been issues in the cache configuration file in older versions, and a nodes eviction and timeout error.

To add additional capacity, the cluster has to be fully recycled and that cause the down time of the environment.

Oracle Customer Support works when we escalate the issue, otherwise first level support is not that good.

The latest version is straightforward, as there is lots of configuration done through the WebLogic console.

We implemented it ourselves. Before implementation, review the requirements thoroughly because if the cache sizing is not correctly defined it creates a major bottleneck. The size of the JVM depends on the size of cache.

• Query response time
• Clustering, data distribution, data affinity

Coherence has improved response times for queries of sizeable data sets. Also by allowing for data distribution and replication through clustering, it improves the reliability of information systems.

• An API allowing for ‘joins’ between different caches, similar to DB joins.
• A more streamlined configuration. There is a multitude of proxy, node, extended client, etc. scripts and config files that need to be maintained. What about making this less of a hassle in future by bringing more consistency into the configuration process?

I've been using it for three years

We had one instance when we experienced intermittent network failure. This issue was not reproducible for obvious reasons. Coherence failed to live up to its SLA by not being able to recover but getting into a state where new nodes were created when the old ones were still there but for some reason no longer recognized as being part of the cluster. The Oracle support was not something to write home about, i.e. there was a constant request for more info (logs, timelines, etc. – which were provided) and never a feeling that the problem was understood or at least that there was any serious attempt at investigating or reproducing on Oracle’s side.

Medium to Good. Sometimes prompt competent responses, at other times support was lacking.

It was a company decision as this is a commercial product with guarantee of support.

It was complex. There are a multitude of configuration files and shell scripts, most of which could be copy and pasted. No uniformity of approach or tool to allow for proper management of configuration.

ROI is reasonably good, since no cheaper alternative satisfying company requirements was identified.

The product is considered expensive, hence the company will be on the lookout for a replacement if feasible. I'm not involved in licensing discussion.

My advice would be for Oracle to prepare a database with already existing configurations from clients. This would help future clients to have templates for various solutions already instead of reinventing the wheel. Generally Oracle fails at this chapter as opposed to open source solutions. It is very painful to start from scratch with little or no concrete solutions posted online (full solutions with commercial value).