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.

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.

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.

The most valuable features are ease of use, scalability without too much work, and failover recovery.

We were trying to get better performance of compute tasks previously developed on RDBMS to cache and it has improved the performance by a factor of 4.

I'd like to see:

• More documentation
• Less/easier configuration
• More IDE support or create a spring-boot starter

I have used this product for around six months.

I have not really encountered any stability issues. I was pleased with its fault tolerance.

I have not encountered any scalability issues either.

We have not made use of any technical support as of yet.

We tried several approaches towards our goal of performance improvement. This was the most likely solution and hence was used.

The tutorials helped, but I use NetBeans, so there was a learning curve, but nothing complicated.

The price is high. I believe there should be a cheaper version for only the caching solution.

We have not evaluated other caching products because this an Oracle product and the product/solution was from Oracle too. We tried some streaming alternatives like Spark, etc.

The product is great, simple, and easy to use and integrate. See if your infrastructure supports it; if there are ways to make it work. Do a PoC before deciding.

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.

• 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.

• Putting and getting data from cache
• Clearing the cache using a batch job
• Querying the cache using Coherence QL
• Trigger functionality used when putting data to cache

Would be good if the initial setup was easier.

Almost 2 years.

It is Okay. Seven out of 10.

We used Ehcache in a previoius project and switched to Coherence. Ehcache should be installed in each JVM but Oracle Coherence is a central place, provides response from cache. Space consumption is much less.

Initial setup is bit complex in WebLogic 12c when compared to WebLogic 10g. Performance is very good in Coherence.

Coherence uses key value pair logic to put data to cache and fetch. If you use immutable object in the cache is it very fast, it takes a nanosecond to put it. It uses PortableObject instead of serialization. PortableObject is lightweight compared to implementing serialization.