It just works

I have been working with the pre-release of Coherence 2.2 for some time and have found it very intuitive to use. The switch from using Coherence 2.1 to 2.2 was simple and we were able to benefit immediately from the performance enhancements in 2.2 with no change in configuration. And as always, the support from Tangosol has been excellent, with questions being correctly responded to within hours.

Congrats to Cameron and the Tangosol team.

-A

Cameron,

  I know that you already listed the details of the enhancements for the new version, but what are the major benefits of using a product like Coherence if a corporation is already using a commercial app server, like WebLogic, which already provides a transactional cache in a clustered WL environment?

Thanks dude,

Raffi

Raffi: .. what are the major benefits of using a product like Coherence if a corporation is already using a commercial app server, like WebLogic, which already provides a transactional cache in a clustered WL environment?

WebLogic does not actually have clustered caching. What it can do in a cluster (in version 7 and later) is optionally use the database to verify that data that it had locally cached is transactionally correct. To use this feature, set the following options:

concurrency-strategy=optimistic
cache-between-transactions=true

As a result, your application will have to be able to handle roll-backs due to stale caches. I cover this and other topics in the presentation that I did for the New England WebLogic User Group. (See also the helpful links at the end of the presentation, including the ones that go to the doc for the above options, and also those on the Seppuku pattern.)

Coherence provides actual clustered caching, such that all servers participate equally (peer to peer clustering) and have a common view of the data (a "coherent" cache.) Coherence even provides transactionally consistent caches in a cluster (supporting isolation levels of read-committed, read-repeated and serializable, and both optimistic and pessimistic transaction models, and even supporting J2CA to plug into the app server's transaction manager.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Thanks for clearing that up, Cameron. It makes more sense to me now, from a "value" perspective.

What if an application is deployed in a non-clustered environment, in that the app server resides on a single machine; would Coherence still be valuable, or not neccessary?

Also, Coherence only supports BMP, right?

Thanks again,

Raffi

Raffi: What if an application is deployed in a non-clustered environment, in that the app server resides on a single machine; would Coherence still be valuable, or not neccessary?

Coherence becomes handy as soon as you have more than one JVM, so if you are running on a single server with only one JVM, there's nothing to cluster. If you plan to eventually deploy to a clustered environment, both the development licenses and the non-clustered production licenses are no-charge, which makes it super simple to scale up an application to a cluster without changing any code.

Raffi: Also, Coherence only supports BMP, right?

Regarding Entity EJBs, yes, we don't support CMP yet.

We have HTTP session management support out of the box for WebSphere 4, Tomcat 4, and all Servlet 2.3 containers. (We're also planning some very cool functionality in this regard for the upcoming 2.3 release, supporting all Servlet 2.2, 2.3 and 2.4 containers.)

We have a simple to use API (JCache is based on java.util.Map), with a ton of advanced capabilities including the transaction support, cluster-wide concurrency control (locking/leasing), distributed queries, grid invocation support, loader support for database caching, write-behind support for writing changes back to the database, etc.

With our partners, you can get clustered JDO support (from several different JDO vendors including SolarMetric KODO JDO and Hemtech JDO Genie), JDBC caching support (Isocra LiveStore), C++ integration support (CodeMesh), and .NET integration support (JNBridge).

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Cameron,

   Thanks for all the info! I appreciate the one-to-one consultation. This info will help me make an informed decision in the future when attempting to pitch a new product to my boss, te-he!. Currently my company deploys all of their production system on single servers, ugh!, and I know in the very near future this will need to change to get away from single point of failures, among others things which need improvement. Anyway, thanks again, you're allright dude! :-P

By the way, Coherence is downloadable for development, right?

Raffi

Coherence is downloadable for development, right?

There is a free eval available for download. We ask for an email address and name to download it.

The developer license is also free, but we do ask for a little more information (standard stuff like social security number, mother's maiden name, bank account numbers, ... just kidding ;-)

Our production license prices and terms are always published on our web site.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Cameron...

When you support CMP you'd probably be bought by one of the "big" appserver vendors and buy your own private Island (and MIG) ;-) Congrats on the release.

Cheers

Smythe

Hell Yeah! Oh man, that would be so sweet!!!! Say hello to a few million, hell, probably more, depending on how valuable the vendor views Coherence as an integral piece for their app server.

After that, you can sip Pina Coladas on a white sand beach in the Carribean! Oh man, what a dream!

Raffi

Hi Raffi,

Hell Yeah! Oh man, that would be so sweet!!!! Say hello to a few million, hell, probably more, depending on how valuable the vendor views Coherence as an integral piece for their app server.
After that, you can sip Pina Coladas on a white sand beach in the Carribean! Oh man, what a dream!

That might be fun for a couple of weeks... but we're having too much fun working on interesting technology, and it's cool to work with a good team of people. However, I wouldn't mind taking a few weeks off to _visit_ an island and drink some beers!

Later,
Rob Misek
Tangosol Coherence: Cluster your Work. Work your Cluster.
Coherence Forums.

Ahhh.....You damn work-aholics are all the same! :-P I hear ya, sell the company, and then what? I know it must be great working on a product that you founded and introduced to the market with success. It's an entirely different ball game knowing that you are working on something that you created, as opposed to working in a corporate environment on a product created by someone else. Best of luck to you guys!


Raffi

Hi Raffi

Ahhh.....You damn work-aholics are all the same! :-P I hear ya, sell the company, and then what? I know it must be great working on a product that you founded and introduced to the market with success. It's an entirely different ball game knowing that you are working on something that you created, as opposed to working in a corporate environment on a product created by someone else. Best of luck to you guys!

Many thanks. It has been a lot of fun (and hard work ;-) working in such an environment. Although, I still have a boss to answer to (good thing it is Cameron ;-).

Later,
Rob Misek
Tangosol Coherence: Cluster your Work. Work your Cluster.
Coherence Forums.

Just wanted to share our experience with using Coherence. We had a requirement to cache > 3 GIG of data in memory for our application. It had to be clustered and fast. After evaluating several products, Coherence made the most sense and fit perfectly into our application. It's like it was custom designed for us. The power of it is that there is no change in the API since we just use Maps to store the data.

With Coherence we now have the ability to distribute our data across a cluster of servers and reduce the heap size of application server. The response times are great(< 50 msec for displaying a complicate large data table).

The support from Tangosol has also been great. They even helped us improving our own code to optimize the use of Coherence.

Great job, Tangosol!!!

I see that the price per cpu is about $5,000 per cpu. I wonder how this compares to building the same application on Oracle Real Application Clusters (RAC). RAC is I think an easy way to scale the database horizontally. There are multiple database instances which use direct memory access over high-speed links. The hardware is going to cost more, and so will the license, but I wonder how much more it's going to be.

And you get some things automatically:

1) Your database is closer to the latest state of the data.
2) Don't have to worry about which cache configuration you will use. The very reason that there is a choice is there is that the nicer the cache, the worse it will perform (more concurrency control, more overhead.)

An interesting comparison. With RAC you would have to constantly go through the JDBC driver, which is a type of serialization. But the distribution of updates is done *synchronously*, as opposed to anything in Java, which goes over IP and must be asynchronously. So the hardware costs more up front, but beyond a certain throughput it should actually cost less, because the machines don't do as many context switches.

It would work also with DB2 on zOS, but that should cost more because we are talking mainframes.

If Cameron could try this out (although I don't know if he wants to), it would be very instructive.

Guglielmo

not necessarily. if your application is talking to database through EJB container for example, container may not be flushing the latest state of the data that entity beans hold to the database. EJB container has the latest state of the data not the database and container decides when to read/write the state from/to database. if you can force the container to be in-sync with database all the time and not use its internal cache then yes you are right.

-talip

Hi Guglielmo,

I see that the price per cpu is about $5,000 per cpu. I wonder how this compares to building the same application on Oracle Real Application Clusters (RAC). RAC is I think an easy way to scale the database horizontally. There are multiple database instances which use direct memory access over high-speed links. The hardware is going to cost more, and so will the license, but I wonder how much more it's going to be.

I don't see them as directly competing. Several of our customers use RAC, and (if you want my opinion) the whole RAC concept is pretty cool. It has a bit higher list price per CPU (IIRC, RAC lists at 16x our price), but it will run on the same hardware (as far as I know).

And you get some things automatically:
1) Your database is closer to the latest state of the data.

Again, I don't see them as direct replacements for each other. For example, with Coherence, just use write-through caching and you get the same result. (You can even use write-through caching to a RAC database.)

2) Don't have to worry about which cache configuration you will use. The very reason that there is a choice is there is that the nicer the cache, the worse it will perform (more concurrency control, more overhead.)

That doesn't sound quite right. It's more like picking the right tool for the job. For extreme scale, you're almost always going to be using the distributed cache service (which is a cluster-partitioned cache.)

An interesting comparison. With RAC you would have to constantly go through the JDBC driver, which is a type of serialization. But the distribution of updates is done *synchronously*, as opposed to anything in Java, which goes over IP and must be asynchronously. So the hardware costs more up front, but beyond a certain throughput it should actually cost less, because the machines don't do as many context switches.

Are you saying that you have some sort of custom network wiring for your RAC setup, as opposed to just clustering over ethernet? Let me know what exactly you're referring to. I've never configured RAC, so I'd be glad to learn more about it.

While we don't have it in our lab, we supposedly run fine on high-speed interconnects like TopSpin. (We don't have any low-level native bindings; we just use the IP stack.)

It would work also with DB2 on zOS, but that should cost more because we are talking mainframes.

Just a wee bit more ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Actually I don't have a set-up, I am just discussing things I have read about - that's also why I don't know the costs.

I think depending on the platform RAC can use what are essentially (almost) zero-copy user-space sockets. The wire could be super-expensive (Tandem used to sell a system-area-network that was like a giant PCI bus), or it could just be gigabit ethernet.

User-space communication is nice because there is no context switch. You send the message out, and a few microseconds later you keep on going. At high throughput the application is mostly sending messages back and forth, so it's nice to cut the OS out of the picture.

.

I think depending on the platform RAC can use what are essentially (almost) zero-copy user-space sockets. The wire could be super-expensive (Tandem used to sell a system-area-network that was like a giant PCI bus), or it could just be gigabit ethernet.

I see. I'd have to do a lot more research on RAC before commenting. I know a bit about Tandem, but mainly because we're seeing some of those apps come over to clusters of "regular" servers. (The Tandem stuff is amazingly reliable once you have it set up and configured well, but it is very expensive to keep running.)

User-space communication is nice because there is no context switch. You send the message out, and a few microseconds later you keep on going. At high throughput the application is mostly sending messages back and forth, so it's nice to cut the OS out of the picture.

Note that for highly concurrent applications on SMP boxes, the context switches are much less a concern. That's because you have a lot of threads asking questions and answering questions, and those few microseconds that they have to wait for synchronous communications are better spent processing a different thread. At several billion operations per second, and with dozens or hundreds of threads per box, it's worth getting a context switch or two in there. Coherence isn't optimized for STP -- instead, it is architected and optimized for highly scalable multi-threaded multi-server applications.

As far as being able to cut the OS out of the picture, and staying in user space without context switches, those topics are well beyond my scope of knowledge. Our product is still pure Java, so I don't know if we can even take advantage of such specific hardware capabilities.

One other thing to consider is that Coherence operates at the object level, while RAC operates at the relational database level. That is why they do not directly overlap. If you need more scalability for the relational database, you can use RAC. If you need to offload some of that into the application server space, which means avoiding a large number of O/R conversions and JDBC latencies, etc., then you use Coherence.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

After reading Ward's sales pitch, your honest opinions, integrity and technical acumen are refreshingly welcome. The industry is better served by product owners like you.

Hi Cameron,

Congratulations to the Tangosol crew on the release of the new version! Feedback seems extremely positive.

Quick question: Where there any enhancements regarding how idimax uses Coherence for job queuing? I noticed how you describe the product as a framework for grid computing, which has some conceptual overlap.

Cheers,
m@

Hi Matthew,

There are a number of things you will very likely find very useful in this realease.

We added the ability to specify the number of worker (daemon) threads for the Distributed and Invocation Services can use, thereby enabling you to increase execution parallelism.

Also, I think the both cache configuration descriptor functionality (to simplify cache configuration and re-configuration without code modifications) and the Invocation Service functionality (for easily distributing the processing of tasks across the cluster to operate on the local data on each node) would be very useful in job-distributor and grid type applications.

Best Regards,

Alex Gleyzer
Tangosol, Inc.
Coherence: Cluster your Work. Work your Cluster.

Sounds interesting. Do you have any best practices for determining the optimal number of worker threads to use, or is the best bet trial and error on a user's particular environment?

Hi Matthew,

If your processes are not CPU-bound, for example your Invocable process accesses external resources that it needs to wait on response from: DB, JMS, file IO, etc.; or your Distributed cache utilizes a CacheStore to get data from DB, then a good number is the combined number of connections to the external resources. So if you are using a CacheStore for your distributed cache that accesses a database, you may want to configure the number of Coherence threads to match the number of JDBC connection pool threads. This way a new request can be processed without having to wait for threads to free up.

On the other hand, if your processes are CPU-bound (in other words if your Invocable process or your Distributed cache do not access external resources) then a good number is based on the number of the server CPUs.

Obviously, the only way to be sure is to load test.

Best Regards,

Alex Gleyzer
Tangosol, Inc.
Coherence: Cluster your Work. Work your Cluster.

I just finished implementing a Coherence plugin for Hibernate.

So, as of 2.1 beta 2, Hibernate apps will be able to transparently switch from JCS as the process-level cache to Tangosol's clustered cache. (Hibernate has a fairly sophisticated 2-level cache architecture ... this applies to the "lower" level cache.)

Took me about an hour and a half between downloading coherence to running Hibernate on top of it! Amazingly easy to get started. I'm very impressed (though I can't do any real performance profiling yet).


I'd love to see some Hibernate users try this out and see what kind of numbers they can achieve.

Any volunteers?