Coherence 3.4 Sneak Preview: Here comes C++!

Last night I had the pleasure of presenting a sneak preview of the soon-to-be-released Coherence 3.4 at the UK Coherence SIG.  While it’s been some time since we’ve seen a new release of Coherence, based on what’s currently in Coherence 3.4, I can certainly see why!  

Although we’ve not yet produced a Release Candidate (coming very soon I hear), I was fortunate enough to get a build earlier in the week and run it through it’s paces.  So far so good.  All of my regular projects (and POCs) work as expected, even the one’s where I’ve customized core components – which is a great first step for any release!

The big ticket item for me though is C++.  It’s not so much that I want to go back to developing with C++ (I’m pretty comfortable with Java at the moment), it’s more that we’ll soon be able to satisfy a lot of very patient organizations.  Given what I’ve seen I’m sure they’ll be a). very happy the wait is almost over and b). very happy with the results. 

[Ok… there are a bunch of other very cool and extremely useful Java & .NET features in Coherence 3.4, but for now I’m going to focus on C++.  I’ll talk about the other stuff in a later post 😉 ].

Probably the biggest thing about Coherence C++ for me at the moment is not necessarily what it does (we all expect it to work), but it’s what we didn’t do that will count in the long run.  Unlike most approaches to C++ <-> Java integrations I’ve seen, the Coherence Engineering team has maintained the philosophy that “if it’s meant to be in language X, then we’ll write it in language X”.  What does this mean?  Simple really.  Coherence C++ is just that – it’s written in pure C++ (using STL)… well so far.

So… It’s not a C++ wrapper around the Java or .NET version of Coherence.  Nor is it a solution where you have to embed a Java Virtual Machine inside your C++ processes or embed your C++ applications inside a JVM.  Additionally you don’t need to write JNI code (and we haven’t either).  It’s a pure C++ Data Grid client implementation that talks directly with the Data Grid using our POF (Portable Object Format).  It uses wirelevel packed byte binary communication – no wrapped XML objects etc.  As requested, it’s “as close to the metal” as you can basically get. 

Like Java, it works across platforms and operating systems. That is, it’s designed to run on the usual suspects, Linux x86 32bit and 64 bit, Windows 32bit and 64 bit, Solaris etc. And… it also manages memory itself (more on this in the future).

Why did we go to so much trouble doing this when we could have easily used a third-party “wrapper” around either of our Java or .NET Coherence implementations?  We figured if you’ve invested in writing C++ to produce high-performance applications, so should we.

[updated] Here’s what some simple code looks like 🙂

//get a named cache (just like Java)
NamedCache::Handle namedCache = CacheFactory::getCache(“remote”);

//insert/update a value in the cache
Object::Holder
prev = namedCache.put(“message”, “gudday”);

//get the current value from a cache
String::Holder
curr = handle_cast<String>(namedCache.get(“message”));

Advertisements

5 responses to “Coherence 3.4 Sneak Preview: Here comes C++!

  1. Andrew Roberts

    This is excellent news. It’s insane just how many Java based HPC products get their C++ interface wrong! This makes the product both a chore to develop for and deploy.

    Yes the C++ API for Coherence has been a very long time coming but that’s because you guys really take the time to do things properly. I look forward to the final release!

    PS: Apologies we could not make it to the SIG. Are the materials available anywhere?

  2. Brian, Where can I read about what Coherence is?

    FYI I’m a C++ dev, not Java.

  3. A good place to start is here;

    http://wiki.tangosol.com/display/COH33UG/Defining+a+Data+Grid

    A solid definition of Data Grids (and of course Coherence).

  4. Is it like C++ client is extend client and how does it compare with Java client in terms of performance. As I understand Java client-no_local_storage communicates over TCMP whereas extend clients over TCP/IP. Again, if it is extend, then I guess between C++ and .NET, I guess the performance should be similar. By performance, I mean data transfer rate, relieving performance of the client SDK for the moment.

  5. The short answer is “yes” to your questions. The C++ client is built very much like the .NET client (but with pure C++) and uses TCP/IP to connect to a data grid (using the *extend protocol with Portable Object Formatted objects on the wire).

    In terms of relative performance between the different clients (as they are all based on the same network technology and protocols), the differences are often down to the language/platform specific optimizations and maturity of the client. That is, while theoretically the .NET, Java and C++ should all exhibit similar performance characteristics, it turns out that maturity of the “client” implementation can be a differentiator in performance between features within clients.

    For now it’s very possible that the Java and .NET clients may out-perform the new C++ client, simply due to the maturity of the implementation. eg: Initially when we released the .NET implementation it lagged a bit behind Java (in terms of performance), however it caught up very quickly. In fact, by the time .NET was released as GA (Generally Available), it out-performed parts of the Java clients!

    I’d expect to see the same with C++ client. It’s new and we (with customer feedback) will find new optimizations as the product is put through it’s paces and matures.

    While we make every effort to ensure consistent performance between the different language implementations, language specific optimizations, together with platform support, may make some clients better than others – for specific features.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s