Oracle Coherence Reviews

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.

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.

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.

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.

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

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.