Oracle Coherence Reviews

High availability, distributed calculation features, and WebLogic integration are the most valuable features to me.

It decreased response times in B2B operations thanks to the grid calculations.

IDEs support and hot deployment have room for improvement.

I have used Oracle Coherence for four years.

I did not encounter any stability issues.

The scalability issue I encountered was that it costs a lot!

The technical support was excellent.

I did not use a different solution before Oracle Coherence. My company was using Memcached before I started working there, but I always used Coherence.

Initial setup was complex because we integrated GAR files in EAR files. We were one of the first customers who were building the cluster, along with the business logic, and deploying everything together in a single operation. We got a complete step-by-step to cover our needs from the post-sales engineering team.

The product is the best, but it's absurdly expensive because licensing is according to the number of CPUs. The only advice I can give is to purchase specific hardware with a few CPUs that are as fast as possible, and with a lot of memory.

We evaluated Memcached, Redis, and Infinispan.

Learn distributed computing first. It's not worth using only as a key-value cache. If interrupted business operations is an important consideration, think about deploying the grid along with an application in WebLogic instead of building a separate and independent cluster.

The most valuable features are the entry processors for their atomic update ability; and the ability to route an event to one specific node in the cluster.

By embedding Coherence and clustering the application, you can eliminate single source of failure problems. 

We use WebLogic as the JMS provider. For technical reasons, we were not successful in clustering it, so we have a single source of failure problem.

I would like to see a more modern API like Hazelcast or Infinispan.

I have used Oracle Coherence for two years.

The product is stable and solid.

We did not try a different solution, but we searched for a solid product with a good reputation in a financial organization.

Initial setup is straightforward, but it takes some time to tune the cache parameters.

We implemented it through an in-house team.

First compare the product to the more open source competitors, like Apache Ignite and Hazelcast.

Caching: It allows applications to cache objects and application-specific data in an in-memory data grid, which provides substantial gain in performance. In my experience, while working on customers’ solutions where performance is a key requirement, along with robustness and stability needs, I have always found Oracle Coherence as the best solution for integrating with different Oracle products and caching data for application-specific needs.

I have worked on different projects that sometimes demand high performance (millions of transaction per day) without compromising availability or sequencing of the flows. Therefore, Oracle Coherence offered the possibility to cache and also allow sharing of cached objects through remote availability of the cache. Oracle Coherence is easy to integrate using any industry-based programming solution and standard products (works very effectively with Oracle middleware technologies). With Oracle Coherence, we managed to decouple many of our backend and legacy systems through limiting many incoming transactional requests and therefore improving performance immensely in such systems.

In my experience, I did find it challenging to use this product when namespace prefixes on the resulting XML object was a requirement. I learned that the default output from Coherence cache used to strip all of the namespace prefixes and namespace definitions if the input XML object had them. And, if the system that retrieves the result doesn’t receive namespace prefixes, there could be challenges with parsing of the output.

It is important to mention that this was experienced when the Coherence cache was used for remote caching and accessed through an out-of-the-box REST API. As a temporary fix, I had to add annotations to all JAXB-generated classes, along with the namespaces of all the involved elements. I think there should be default support for namespaces and their prefixes, when JAXB classes are used as object factories (generated from schema definition files (XSD)). Over time, with XDD changes, we had to generate new JAXB classes, and had to bump namespaces manually through annotations and bundle the object factory.

I have used it for around three years.

I encountered stability issues sometimes, but that was mainly due to the wrong cache configuration used in implementation. Wrong configuration causes an impact on how objects are serialized or retained, etc.

I have not encountered any scalability issues. In fact, we had a configuration that allowed the cache to fill up to its limit and then was flushed when entire cache was fully occupied.

Oracle support was really good in cases when I had troubles with implementation. Also, when I asked the question regarding namespaces as mentioned, I received very good cooperation.

I did not previously use a different solution.

Installation was rather straightforward and usage was simple. But the complex part was mainly using PofSerializer, which did not work that easily for me and we ended up using a standard Java serialiser in the end.

I am not sure about pricing and licensing, but what I remember from my experience, if a customer has a WebLogic license, it should be ok to use the Coherence cache. But I might be wrong.

Before choosing this product, I did not evaluate other options. While using the Oracle Fusion Middleware stack, it was always our preferred choice due to its integration capability with available tools.

Caching in an important element in order to gain a stable and high-performing system. Therefore, it is important that this product, which is designed to help, should be implemented in the correct way. There are different architectural patterns that can be referred before using cache, best practises regarding cache and invalidation schemes around objects. It is also important to consider the reliability of the object state during usage and also to make sure that its usage is compliant with Oracle’s best practises regarding cache.

One of the features that is greatly used by us is clustering, as it allows us to scale easier by creating more and more nodes.

Coherence has helped us to drastically reduce the request time of our web applications.

Documentation and community support is the first area with room for improvement. Then, an easier configuration mechanism wouldn’t hurt. And also debugging and error management.

I have used it for two years.

We have encountered stability issues. We have nodes failing all the time, especially because of timeouts caused by node synchronization, but occasionally there are also memory-related errors.

We have encountered scalability issues. Currently, we have multiple clusters of six nodes each. At one point, we tried to scale to 12 nodes. We started to have a lot of nodes crashing, most probably because of all the node chatter.

I would say technical support is a 4/10.

I did not previously use a different solution, but if we would do the application from ground zero, we would, most probably, choose Hazelcast.

Initial setup is somehow complex, as you have to configure the hosts that will hold the Coherence nodes, every cache that you set up and all of the domain classes to be used for serialization.

Look into the direction of open-source solutions.

Before choosing this product, I did not evaluate other options, because our company has a “Use Oracle Products” policy.

Look attentively at other NoSQL solutions, and if they really need a caching solution, then look at Hazelcast.

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.