Oracle Coherence Reviews

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.

• Event driven architecture
• Portable object format
• Live events
• Active - passive replication
• Cache schemes
• Distributed
• Near scheme
• Eviction policies

The improvement on features of Tangosol Coherence during 2006 through 2009 was limited, but the best feature was the standalone. After 2013, integration with Oracle has added many features which have not been used much, or the industry is not ready for the features. It has become very heavy along with the price for Oracle's integrated product as a fusion middleware.

The product has a big miss for troubleshooting, auditing, and monitoring for new features like live events, live objects, etc.

I have used Oracle Coherence for more than 10 years, from version 3.5 through 12.1.2.1.

No.

No, from a product perspective.

Yes, from a license cost perspective.

A six out of 10, as it depends on your relationship with the vendor.

No.

It is costly compared to competitors in the in-memory caching market.

Look for open source with better support on monitoring, auditing, and cloud support.