3 Replies Latest reply on May 30, 2008 9:30 AM by manik

    JBossCache vs JMS vs JGroups

    bob_ninja

      I am not sure which to use and what the distinction is. I understand that JGroups sits below the 2, and is a lower level API. Fine. But how do you decide between a caching API (JBossCache) and a JMS API (JBoss MQ)?

      My app consist of several modules (web app in a J2EE server plus several other specialized servers) that are clustered. It has certain transient state that may change at medium to high frequency, so database is not a good place for it. This state needs to be shared/accessed between modules as well as different machines in a cluster.

      Now there are a lot of choices:
      1) Java Space API
      2) Java Caching API (JBossCache)
      3) JMS API (JBoss MQ)
      4) lower level JGroups API

      The "safe" choice would be (3) messaging. However, JBossCache is specifically designed for sharing of beans between multiple VMs, so seems like a better choice.

      I guess my problem is that cacheing and messaging APIs are so close/similar that I am having a hard time choosing between them. Help.

        • 1. Re: JBossCache vs JMS vs JGroups

          I am also facing similar dilemma. Any suggestions which one of the two JBoss Cache/ JMS is better in terms of stability, performance.

          • 2. Re: JBossCache vs JMS vs JGroups
            belaban

            JMS and JGroups are both transports, so they are both conceptually *below* a replicated cache (like JBossCache or JavaSpaces).

            The diff between JGroups and JMS is that JGroups' focus is on flexibility and extensibility of the transport implementation, whereas JMS only provides you with the standardized interface, limited possibilities to replace parts of the JMS impl you use with your own stuff.

            In other words, JGroups can be tuned much more.

            If you want to replicate data, JBossCache is a natural choice. If you wanted to use JMS or JGroups, you'd have to implement the following things yourself to come up with a replicated cache:
            - Replication (blocking versus non-blocking)
            - State transfer to a node joining the cluster. This can be tricky if we do this while other nodes are replicating changes
            - Transactions (atomicity across the cluster)
            - Cache loading / eviction
            etc etc etc

            • 3. Re: JBossCache vs JMS vs JGroups
              manik

              Don't forget concurrent access. If you want your "cache" to be threadsafe, there will be a lot to do by way of locking to prevent reading invalid state.