Tangosol releases Coherence: Distributed Cache Product

Discussions

News: Tangosol releases Coherence: Distributed Cache Product

  1. Tangosol Coherence is a coherent cache product designed to work cooperatively with the leading application servers, including Oracle 9IAS, BEA Weblogic, IBM WebSphere, Sun iPlanet, JBoss and Caucho Resin. Coherence provides dynamic failover and load balancing features, eliminating bottlenecks and single points of failure.

    Check out Coherence at: http://www.tangosol.com/products-clustering.jsp

    Threaded Messages (19)

  2. I am very surprised that no application-server vendor have successfully incorporated one of many cache managers out there to offer a 'cache powered cmp' which is so much missed.

  3. Hi Yuval,

    Yuval: "I am very surprised that no application-server vendor have successfully incorporated one of many cache managers out there to offer a 'cache powered cmp' which is so much missed."

    We are looking at providing Coherence functionality to work with powerful CMP products such as CocoBase. The nice thing about CocoBase is that it was architected with caching in mind; see the "Performance Cache Systems" section at:

    http://www.thoughtinc.com/cber_tools.html

    You can also look at WebGain TopLink and TimesTen FrontTier. They are both good (but expensive) products.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  4. My company recently contracted with Tangosol to implement their Coherence product into our J2EE application. We had several caches that would have been problematic in a clustering environment. We looked at Sun's recommendation and were not satisfied with it's single point of failure. Cameron and Rob came to our site and in a few days had integrated Coherence, updated our build process and changed our caches to use Coherence. The product is easy to use and performs phenomenally. I would recommend this product to anyone that is using J2EE and wants to cluster.

    Patrick

  5. Hello!

    I've been working a lot with WL6.1 clusters (4-way) and
    other J2EE products. I have to say, I'm still wondering
    how J2EE can be a standard for clustering APIs *at all*
    without including a distributed cache. The cache is
    ultra-essential in almost any clustered application I
    had to write so far. I'd really like to have a standard
    and open-source implementation. "Naive multicast" takes
    you only so far... I'd exchange the larger part of the
    EJB spec for a distributed cache.

    Cheers,
        Henrik
        TNGtech
  6. <quote>
    I have to say, I'm still wondering how J2EE can be a standard for clustering APIs *at all* without including a distributed cache.
    </quote>

    Distributed cache is certainly an inherent requirement for a failsafe cluster. Cant comment about other server's clustering solutions.. but Pramati server supports completely failsafe EJB clustering. Without needing the apps to use any APIs. The distributed-cache is built into the persistence layers of the app server. A distributed fail-safe lock-manager with cache replication mechanisms enables high-performance access to the data (so much so, that as nodes are added the thruput is almost proportionally increased!).

    Ramesh
    - www.pramati.com
  7. I'm playing with Coherence since it was released, and it is a very cool product (and so are Tangosol guys - response time/quality to bug reports, questions, suggestions etc is phenominal).

    Anyway, there are free solutions, JavaGroups for example. If you do not mind some coding, JavaGroups can be used for all sorts of clustering solutions/add-ons, including caching (there is a replicated hashtable example).

    --
    Dimitri
  8. Anyway, there are free solutions, JavaGroups for example.

    >If you do not mind some coding, JavaGroups can be used
    >for all sorts of clustering solutions/add-ons, including
    >caching (there is a replicated hashtable example).

    Hey, where are the JBoss Gurus? I've read in the JBoss 3.0 clustering documentation that this JavaGroups is used in the JBoss clustering implementation. Note that JBoss 3.0 is still in b├Ęta.
    Can somebody from Coherence compare JavaGroups to Coherence? Are these products designed with the same goal?
  9. Pieter: "Can somebody from Coherence compare JavaGroups to Coherence? Are these products designed with the same goal?"

    Some of the JavaGroups goals are the same or very similar to those that we laid out when we implemented TCMP (Tangosol Cluster Management Protocol). JavaGroups is based on a "protocol stack" that allows arbitrary loosely bound "protocols" (basically, event passers that plug into other event passers, with the bottom one in the stack actually doing something on the network) to be bound together to send information across the network. Depending on which JavaGroups protocols you select, you can achieve different levels of QOS, including guaranteed delivery, in-order delivery, support for multicast, support for unicast, failure detection, message chopping / gluing, etc. Our TCMP implementation povides all of these QOS features by default, and appears to do so with a lot less overhead.

    Coherence is a coherent cache implementation built on top of TCMP. It exposes a ConcurrentMap (extends java.util.Map) interface for each clustered cache that your application needs. The data is accessed and mutated via the Map interface (like JavaGroups' DistributedHashtable) and the data is kept synchronized across the cluster (not guaranteed by JavaGroups' DistributedHashtable). Furthermore, using the ConcurrentMap interface, it is possible to apply concurrency controls to the cache (which it does internally on operations such as put and remove). I think that JavaGroups has a token-passing protocol (basically, Token-Ring(tm) over the other JavaGroups protocols) that would allow the DistributedHashtable to stay synchronized (at a large cost to scalability) -- otherwise I don't see how it can guarantee to keep the data in sync (such that all members see the same data). However, I'm not a JavaGroups expert, so perhaps you could check with Dimitri or post a question on their list groups.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  10. Some of the JavaGroups goals are the same or very similar

    >to those that we laid out when we implemented TCMP.
    >...
    >Our TCMP implementation povides all of these QOS features
    >by default, and appears to do so with a lot less overhead.
    >
    >Coherence is a coherent cache implementation built on top of TCMP

    Thanks a lot for clarifying things,
    Pieter.
  11. Hi Pieter,

    I did a little more research on JavaGroups. I created a test to compare performance. On my notebook, two Coherence cluster members could simultaneously load 1000 1KB items into the cache in under 10 seconds (5 seconds for one member, 10 for the other).

    The current release of JavaGroups (1.0) has a DistributedHashtable as I mentioned earlier. Using a simple test script, I tried to load test it, but it locked up. Dimitri pointed me to some known issues with 1.0 that state that DistributedHashtable does not work in 1.0 and you must use 2.0. I downloaded 2.0 (which is not finalized yet) and tested the latest fixes to DistributedHashtable using the properties provided in the JavaGroups DistributedHashtable test. Because the test was taking too long to run for 1000 items of 1KB each, I scaled it back to only put three items into the cache, each was just ten bytes. The test completed in exactly 120 seconds for one cluster member and 102 seconds for the other. Coherence executed the same test in zero seconds.

    I doubt that is indicative of how it would work if configured correctly, but I can't figure out how to set it up (I used the JavaGroups test code). I will ask Mettu Kumar next -- I think he is involved with JavaGroups.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  12. Hi Pieter,

    I finally got JavaGroups working with Dimitri's help and a few more days of analyzing stack traces and reading source code. The final problem was related to a reverse DNS lookup in some debug output, so I rebuilt everything with the debugging all turned off. (You have to download and build the in-process 2.0 sources since the 1.0 release locks up; note that 1.0 is the current release.)

    Testing vis-a-vis our "simple" replicated cache option (which, just like JavaGroups, does not guarantee any data coherence), the JavaGroups implementation averaged about 6x-7x slower, and could sustain only about 1/7 of the data throughput while consuming over 2x the CPU cycles and requiring over 4x as much memory. Also, JavaGroups experienced out-of-memory errors when replicating 100,000 100-byte pieces of data (total of 10MB) with a 256MB heap.

    Peace,

    Cameron.
  13. Hi Cameron,
    thanks for all the testing.

    Caching seems to be a rather hot topic. What about all the claims made by eXcelon Javlin and Versant enJin stating 40-50 x speedup?

    I will attend some web seminars concerning these claims, but they will be biased anyway, so has anybody tried out these products in production systems?

    I'm curious how much speedup can be achieved for systems that are not the perfect natural fit for caching.

    Regards,
    Pieter.
  14. Hi Pieter,

    There are a number of good C/C++ products out there in the "in memory" or OODBMS or "distributed database" market, including the ones you mention and also TimesTen, Persistence, and Poet. They all provide some level of Java interfaces to their products.

    Our pure Java implementation removes several potential issues with platform support, reduces latency and resource usage (no JNI), improves stability (no native code), and makes packaging, deployment and support easier.

    On the network performance and scalability side, nothing is faster and more scalable than our TCMP implementation. Our protocol implementation is a "constant-order" implementation (big-O on the order of K), meaning no matter what the load, absolutely no operation will degrade in performance (which is _very_ hard to accomplish). We support ATM, burst mode, positive and negative acknowledgement algorithms, message bundling, configurable unicast and multicast, and configurable multi-threaded handling.

    Ours is also the easiest product to use. With support for java.util.Map all the way up to JTA/CMP EJB, it supports standard well-known interfaces, and requires just one JAR to be added to the class-path to install. It is fully configurable, yet self-configuring by default, so you can start using it immediately without learning how to configure it.

    Lastly and most importantly, when it comes to price, Tangosol Coherence wins every time. Most of the other "solutions" start at US$100K and up for production use. A Coherence cluster on 4 fully loaded 4xCPU Sun servers (e4x0 series) would cost less than US$20K total.

    In summary, not only is it unbeatable in performance and scalability and resource conservation and configurability, not only is it the easiest solution to use, not only does it have all the benefits of being built in pure Java, but it also comes with the best price tag. I guarantee it.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  15. The product is not exactly cheap[ Go to top ]


    I just checked out the pricing. At 3,5k $ per CPU,
    fitting our cluster with the cache would cost a
    whopping 50.000$. That's a lot of money :(

    Cheers,
        Henrik
        TNGtech
  16. The product is not exactly cheap[ Go to top ]

    Hi Henrik,

    Thanks for your interest in Coherence!

    Henrik: "I've been working a lot with WL6.1 clusters (4-way) and other J2EE products. I have to say, I'm still wondering how J2EE can be a standard for clustering APIs *at all* without including a distributed cache."

    I think Orion supports it through the ServletContext object and JBoss now has some support for it. Weblogic has clustered JNDI, but it suffers from collision problems (by design ... it is good for JNDI just bad for caching).

    What Coherence provides is a coherent clustered cache, one that provides synchronization (via the ConcurrentMap interface) and ease of use (via the standard Map interface).

    Henrik: "The cache is ultra-essential in almost any clustered application I had to write so far."

    I absolutely agree. We saw that need, and address it with Coherence.

    Henrik: "I'd really like to have a standard and open-source implementation."

    I've seen at least three "open source" implementations of a "clustered map" object. One by Acelet used a database as the cache, which (in my experience) is what the cache is trying to avoid. Another one, which I cannot find right now, uses multicast to publish a fraction of the cache at a time, repeatedly publishing the entire cache just in case the multicast packets get lost. The third and newest is JavaGroups, which is hosted on SourceForge and can use multicast and unicast UDP sockets (like Coherence).

    None provides the concurrency features that are inherent to Coherence but you do have the ability to build such a thing yourself if you download the code and write the new feature (particularly with JavaGroups ... it seems to have the most flexible architecture of the open source options).

    It is the usual "build vs. buy" scenario. Coherence is very carefully designed and packaged to require minimal effort to implement in an existing application, and it performs and scales very well compared to the other existing solutions.

    If you already downloaded the Coherence eval, note that the latest build (build 22) is available as of today and is completely self-configuring, so you don't have to provide any network configuration information or environment variables whatsoever to use it. (It is also completely manually configurable for those situations where the administrator wants to control the configuration; see the FAQ for details.)

    Henrik: "3,5k$ per CPU"

    The current price for the Coherence product is $1695/CPU with a list price of $2495/CPU; (the $3495/CPU price that you mentioned is for a different product). With the bundles we are announcing in the first week of the new year, Coherence for your 16 CPU network would cost less than $20k. (That's about the same cost as 1 CPU for the clustered BEA Weblogic that you said you are using.)

    If you would like more information about Coherence, please email sales at tangosol dot com.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com
  17. Hello again,

    you mentionend JNDI clustering in WL as a possible way of implementing a cluster-wide cache. Not so (IMHO).

    When BEA deprecated "BEA Workspaces" and migrated to 6.0, they officially specified that their clustered JNDI should be the replacement technology for workspaces. In our group, we believed this and wrote a JNDI-based cache. Not a good idea (but we may have had some know-how limits at the time). But in any case, especially on cluster restart, I had the impression that JNDI sync can be rather slow (sometimes 15 minutes). We discarded the technology.

    And voila, in WLS 6.1 the documentation changed. Now, BEA explicitly states that you should NOT (!) use JNDI clustering as a caching substitute. Oh well. How many Euros of our developer time went into realizing that the migration strategy was a bad recommendation? You don't want to know :(

    Cheers,
        Henrik
        TNGtech
  18. Hi Henrik,

    Henrik: "you mentionend JNDI clustering in WL as a possible way of implementing a cluster-wide cache. Not so (IMHO)."

    I agree that it is not a good means for caching. For a few small objects, such as semi-dynamic configuration information, it can work acceptably.

    Henrik: "JNDI sync can be rather slow (sometimes 15 minutes)."

    There are several potential problems with WL's JNDI sync when using it for caching, including performance, collision handling (e.g. simultaneous updates) and timeouts caused by too much data being replicated.

    Have you had a chance to download Coherence and see if it addresses some of the needs that you have?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  19. The Tangosol Coherence 1.1 preview is now available for download from:

    http://www.tangosol.com

    Improvements include support for all serializable keys and values, a significant performance increase, and a new optimistic caching option with support for a size-limited cache with an MRU- and MFU-based pruning algorithm.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  20. The Coherence 1.1 release was finalized today and a free eval copy is available for download.

    This version includes support for size-limited caches, automatic entry expiry (i.e. discard each cached item after it has been in the cache for 5 minutes), prioritization based on MRU+MFU, schedulable and periodic cache flushes, and a Javabean event model for tracking changes to the cache.

    Peace,

    Cameron Purdy
    Tangosol, Inc.