Oracle Coherence Reviews

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.

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.

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.

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

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

While you can have a successful career with Coherence just being a get/set man, its true power is realized when you leverage the full scale of the cluster as a whole and exploit its distributed processing capabilities.

For the use cases I’ve implemented, the features I used most frequently and have gone head-to-head with incumbents are as follows:

• InvocationService - I have to admit that I took this for granted up until I went against IBM’s eXtreme Scale. Most organizations want to preload/warm the cache and the InvocationService allows you to issue commands to each member in a distributed manner. Parallelizing this activity gains economies of scale since the load time and rebalancing can be kept to a minimum. Said another way, a million rows can be loaded in the time it takes to load 100,000 if you have 10 storage enabled members. Each member is issued a command which details what rows it is responsible for loading. Coherence provides a number of the libraries required to handle this including ‘retry’ functionality hooks and abstracts all the threading/concurrency logic which would be a nightmare to sort out; as IBM learned on this project. This is in direct contrast to extremeScale’s capability - which relied on leveraging Java’s Executor classes. Basically, they had to roll their own distributed processing engine while on-site.
• Filter, Aggregators and EntryProcessors - Before MapReduce & Hadoop came on the scene in such force Coherence had equivalent functionality that was much easier to use. Filters provide the ability to use conditional boolean logic against your data Out-Of-the-Box. Many fail to realize how powerful this is. In the bake off extremeScale had nothing close to this and therefore had to code it. The requirement was to port a StoredProcedure’s logic, which took 30+ secs to run, into something the grid can run. The implementation was based on an EntryProcessor that leveraged Filters and Aggregators. While I would love to say it was strategic coding ability, it wasn’t - I merely used OOB tools. The end result was that the EntryProcessor, running a complex workflow, was a magnitude faster than IBM’s get() call.
• POF - Portable Object Format is the binary optimized proprietary Coherence serialization. It provides staggering Object compaction. For example, an Item object that was 750 bytes with Java serialization is 31 bytes with POF. This has a rippling impact across the entire app, the cluster, even your network since it needs to handle the chatty cluster members.

The biggest improvement is in speed - everything is faster from record retrieval to workflow processing.

Tooling around complex cluster config files so issues can be identified before the cluster is stood up - and subsequently collapses. Cluster management tools that are independent of WebLogic. Dynamic cluster config rollout and rollback. Ideally this would be used in dev as a prod cluster should be locked down. I’d also like to have some sort of GUI (out of the box) that illustrated cluster member vitals; storage, heap, offHeap, watermarks, evictions, etc.

Monitoring and configuration could be easier while support for streaming data windows and the like isn’t available yet. Moreover, native cron(scheduling) capabilities and an Async API would be a nice to have but those challenges can be overcome with 3rd party libraries. Lastly, native security features would alleviate some concerns and workarounds however, I fully understand impact on performance...

I’ve used Coherence since 2008. I transitioned into consulting where I led a number of projects across several organizations to define, install, and integration clusters for maximum impact on critical business systems.

I have only needed an assist from Oracle once and the issue turned out to be a config problem. The organization had a healthy support agreement and Oracle was able to turned it around quick. Perhaps one of the reasons I haven’t engaged them more is because I jumped into the community early on. I attended every Coherence SIG [Special Interest Group] meeting that I could and became friendly with a few of the developers.

Coherence is very easy to get running locally. Standing up, or defining a cluster for that matter is another task entirely. Each cluster has many ‘knobs’ to dial in. While this offers great flexibility, one should exercise caution when getting into areas of the config that are not understood.

The objective of the project and the performance need to be kept in sight. Here are some questions to help drive the configurations files: Is your project read or write heavy? This will dictate if you should have more smaller nodes vs less larger ones. Should they be storage enabled or not? How much data does the app generally use, would a near cache be beneficial? How often is your reference data used, how much is there determines if it should replicated or not. How many members should there be? Do I need to use a prime number somewhere? Why? Do I need eviction policies, what should they be based on? How do I tell if my cluster is too chatty? How will other apps leverage the cluster? Should I use WKA? Will that prevent new members from joining?

It goes on and on and we didn’t touch DR or monitoring.

I’ve done both and in most cases the projects didn’t have proper momentum until a SME was introduced and the questions above could be addressed. Most folks apply relational thinking towards a cluster and that generally doesn't end well. While you can use rich objects, I’d look for a different model - something flat. Or you need to strictly define your cache strategy to keep hierarchies together (hard to do).

A side by side POC was done with IBMs eXtreme Scale on a project. I also have experience with Gemfire - and wish I didn’t.

Take the time to learn it and test all assumptions. For example, I was using push replication [PR] to satisfy a client's disaster recovery [DR] requirement. All of a sudden the primary cluster collapsed - ran out of memory despite having high watermarks configured. As it turned out the DR site connection went down and PR calls started to queue. The high watermark calculation did not know about the PR queue. This was very subtle use case as I didn’t consider what would happen to the PR calls if the other end wasn't available.

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.