Oracle Coherence Reviews

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.

• Distributed caching
• Aggregation
• Near caching and expiring policy configuration
• Master nodes and dynamic scaling

This product helped our organization to focus on implementing business logic without worrying about scalability on user loads of huge data queries. Application latency improved drastically with the ability to scale with load.

Better support for complex aggregation and atomicity of data. Configuration and nomenclature require more simplicity to understand for new developers.

Four years.

Mostly, it has been stable other than encountering full GC cycles occasionally.

No.

FIve out of 10.

We did not have a previous solution.

We chose this product, because it was one of the most popular distributed caching in memory cache, which supports capabilities like Cassandra and MongoDB.

It was complex and hard to understand the hidden capabilities. Documentation requires more crispy detail rather than lengthy.

You can evaluate Hazelcast, which looks promising.

• 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 EntryProcessor allows you to leverage all of the hardware running Coherence, so you can have a truly grid computing architecture. The feature basically allows you to send logic to the place where the data resides. Because Coherence distributes data across all of the nodes it is running on, you can deal with a massive volume of transactions with maximum scalability.

We are benefiting from performance, thanks to Extreme Performance and innovative architecture.

More simplified configuration would be helpful. Currently, all of the settings are put together in XML files. If you have a complex configuration, that config file could be more than a couple of thousand lines. This is an entirely manual job, so it is very error prone. And the settings are really sparse, either on multiple XML files or command line parameters. There should be some sort of GUI tool with which the user can easily drag and drop to configure, streamlining the configuration process.

I have used it for eight years.

I have not encountered any deployment, stability or scalability issues.

Technical support is 8/10.

Initial setup is very complex; specifically, a lot of XML effort is required.

An in-house team implemented it. You need to have some level of experiences to: 1) understand the product, and then 2) make the best use of it. Everything requires a learning curve, but especially with Coherence, that learning curve is quite stiff.

ROI would have been much better if there was no annual recurring support fee of 22%.

We also evaluated Hazelcast and Infinispan. Simply, Coherence is better than those two. Coherence absolutely outperforms others in terms of scalability, reliability, and performance.

You need a person with expertise to ramp up quickly. As I’ve mentioned, there is a stiff learning curve, and it can only be avoided with the right person.

We use Coherence to keep aware of critical data. We have millions of customers whose data is in Coherence. Previously, when we stored customer data in the database, it took about seven minutes just to locate one customer profile. About 90% of customer data is static. Since we implemented Coherence, this data is in memory all the time; so the results are found in milliseconds instead of five seconds. Our response time for customers calling us over our portal has reduced drastically. We are now able to provide service to our customers much faster. This is amazing, especially for our customers.

It has really transformed the speed that we can respond to customers. Now I don't need to worry about increasing my customer base. I used to wonder how I was really going to provide service to over five million customers. Generally, as the number of customers goes up, the biggest challenge is to provide the same kind of response time. Now I don't need to worry about it. I can just keep growing our customer base, but our response time tends to remain the same.

Reloading really takes a lot of time.

We are already using it for a couple of years.

It is a stable product. We don't really have any issues. The only thing that we really need to think about is when we need to reload the whole thing, especially if we need to do some patching or maintenance. That really takes about 24 hours. That's the downside. It’s something that we are now living with. So we really take that hit on that. Generally, that's why we really plan our maintenance.

I think now I really need that more in a hardware way; but I would really not find that as a challenge anymore. We are actually able to do it more comfortably because now, whether I'm scaling up or scaling down, it's very transparent.

I can't really live without Oracle technical support. There are times when we have so many challenges and into so much trouble and so many issues. They are very helpful. Without them, I would say we can't even function; so they are really good. We have platinum support, and we are able to get their support. Sometimes there are escalations which we need to go through to get the right SLA engaged. But I think we are really getting critical support.

We did not have a different solution before. We were looking for this solution. The response time is the key. It was really touching. When we really started with five million customers, the response time was four seconds. The customer base was increasing, and that became five seconds; and then six seconds. It just kept going up. So we thought we needed to come up with some solution for reducing the response time.

We were looking for a cost-effective solution. Nowadays, any business must keep the operating cost in mind. Why do we want to go for the cloud? Because we are spending so much on the hardware. I really want to make sure my investment in hardware brings a good cost-effective return on the investment.

I keep everything in mind. Of course, I also look for the security and scalability.

The initial setup was neither complex nor really easy. It was somewhere in the middle. I didn't really involve myself in that directly. I am one of the heads of the site. I just fed them the data. It was pretty much implemented by mid-level people; so I don’t really know what the challenges were.

I think this is the only solution we considered. Whenever we really look for a product, first we look whether Oracle has something appropriate. I have been using Oracle for a number of years. I think they always have a solution. They started with the database. Now they have the middleware and the hardware. They have the complete application solutions. You name it and they have it.

Coherence had all the features and benefits we needed.

Look into Coherence’s features. Get a demo first and evaluate whether you can really make use of this product.

Near cache and the ability to implement various strategies, like write-behind and read-through cache.

Basically reducing response times to extremely small latencies in their apps.

The Java interface for loading data through the cache from the database was pretty basic. Also, the process of packaging all dependencies to do were rudimentary.

I started using Oracle Coherence in 2008. I have been using the most recent version for six month with two clients (in the banking and cosmetic industries).

None.

None, but there is a considerable important challenge with record versioning and serialization that needs upfront care decisioning.

We just had an issue running Coherence over Solaris containers. Nothing that actually prevented it to run, but the support was standard support quality from Oracle.

Not before, but after Coherence, we had the chance to work for years with Hazelcast. It's an open source and a cheaper competitor.

Very easy. The XML config files were clear how to configure.

Price is very high - as for any Oracle product.

None. I work as a Oracle partner, so there is no way to consider other options.

Do good decisions on serialization and versioning of objects and don't rely on it as the sole source of data, no matter how much energy output it takes to keep its cluster up and running. Rolling out updates can be challenging if you have to write-behind in place. For example, you need to be able to identify that there is nothing waiting before a full shutdown.

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.

• Portable object format (POF serialization) that allows objects to be serialized/deserialized between Java and .NET.
• Cache dashboard monitoring that provides reporting at the summary and detail level, such as cache hits and cache object count.

The project involved Java back end and Microsoft .NET front end. The product Portable Object Format (POF) allows the two platforms to exchange data seamlessly.

Data transfer performance over geographical locations. Oracle database has better performance compared to Coherence when accessed from different regions.

Two years.

No, as long as we ensure we have 4x memory capacity than the objects that we want to keep in the cache.

No, the product supports clustering for different nodes (data, extend).

I didn't work with the technical support.

I used .NET in-memory cache and this has a single process limitation, hence each node had to keep its own data. Oracle Coherence excels as it is a distributed cache.

For development work, I usually run Coherence on the development server which has more memory capacity.

Based on my understanding, the license is quite expensive.

No, I didn't, as Coherence was the strategic cache product to use.

It is very important to understand the cache size requirement. Do read the cache size calculation from the documentation to ensure you have enough memory/storage for your data.