Announcement Announcement Module
Collapse
No announcement yet.
Clustering with Spring - best practices? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Clustering with Spring - best practices?

    What's the best way to implement a distributed, clustered Java application using Spring? (Without using EJBs...)

    Does anyone have a good success story to share?


    Thanks

  • #2
    Can try terracotta for Spring.
    http://www.terracotta.org/

    Comment


    • #3
      From searching the web and these forums, there looks to be a few ways to do clustering:
      1. Tangosol Coherence
      2. Terracotta
      3. Cluster4Spring
      4. Homebrew lookup service using a distributed cache

      Coherence is commercial, and probably requires a large time (and $$$) commitment to properly evaluate.

      Terracotta has a lot of buzz, but I'd like to hear from people who've actually used it successfully in production.

      Cluster4Spring I've only seen recently... not sure how viable it is.

      And the homebrew option, while feasible, is hack-y... (why doesn't Spring support something like this out of the box?)

      Thanks,

      Comment


      • #4
        First of all, why do you want to distribute and cluster your application?
        I know that "clustering" sounds cool, but what exactly do you plan to cluster?

        E.g. if you want to cluster your Web load, you will be happy with Tomcat/Resin, they both support session clustering.

        Comment


        • #5
          I'm not talking about clustering HttpSessions.

          For example, I'd like to have an 3-tier architecture, with separate (Java-based) web-tier and services-tier. Both tiers should be clustered for failover and load balancing. In the web-tier, you're right, I can use HttpSession clustering. But what is the Spring way of clustering the services tier?

          Comment


          • #6
            What is a clustering in your mind?

            Comment


            • #7
              What exactly are you trying to cluster in the middle (services) tier?

              Typically all Spring beans are stateless singletons, or at least thread safe singletons, so there is very little value clustering them.

              Maybe a concrete use case would be useful....

              Comment


              • #8
                Sorry, should have been clearer. I meant cluster in the same sense that you would cluster Stateless EJBs. There is no bean state to replicate, but you have load balancing and client-failover across multiple nodes.

                Comment


                • #9
                  Originally posted by Patrick Angeles View Post
                  Sorry, should have been clearer. I meant cluster in the same sense that you would cluster Stateless EJBs. There is no bean state to replicate, but you have load balancing and client-failover across multiple nodes.
                  If you use only a web-container the web server (tomcat, resin, etc) cares about load balancing. If you use EJB container it cares about load balancing. Where are you using spring?

                  Comment


                  • #10
                    Here is an excellent example of clustering a Spring app

                    Checkout: http://www.javaworld.com/javaworld/j...31-spring.html

                    Spring makes this solution so easy and non-invasive. It is easy to replace the author's JBoss cache with ehCache or Terracotta, without changing your service pojos.

                    Comment


                    • #11
                      Originally posted by Patrick Angeles View Post
                      Sorry, should have been clearer. I meant cluster in the same sense that you would cluster Stateless EJBs. There is no bean state to replicate, but you have load balancing and client-failover across multiple nodes.
                      But *why* would you want to cluster stateless beans? You can get failover and load balancing without clustering....clustering is really only for sharing state across nodes.

                      Think about it

                      Comment


                      • #12
                        What is your definition of cluster?

                        Originally posted by yatesco View Post
                        But *why* would you want to cluster stateless beans? You can get failover and load balancing without clustering....clustering is really only for sharing state across nodes.

                        Think about it
                        I read this off wikipedia: "A computer cluster is a group of tightly coupled computers that work together closely so that in many respects they can be viewed as though they are a single computer."

                        I agree with this definition. I don't agree that clustering is only for sharing state across nodes. To me, if I need high availability of servers, that means clustering. Now, everyone does clustering a little differently, so you have to evaluate what the product you are considering actually offers. Does it provide the most efficient, and hopefully least invasive solution? I think Spring makes it easy to plugin such a solution without changing your POJOs. http://www.javaworld.com/javaworld/j...31-spring.html demonstrates this for a stateless service. You are not going to tell me that having multiple servers, providing the same stateless service, is bad, are you?

                        Comment


                        • #13
                          Yes, you are of course correct. I wasn't being clear.

                          My point was that the load balancing can happen outside of the application, i.e. with Apache or a hardware load balancer. Each "node" can work independently from the others as there is no state being replicated, hence no server affinity.

                          If the web tier state is replicated, then making the middle tier cluster aware has little or no advantage.


                          From what you say, I see no problem deploying N instances (with the web tier replicating state) and then having Apache distributing the calls (round robin etc.)


                          The question that I was asking, is exactly what benefit do you get about introducing clustering into the middle tier itself?

                          You can of course introduce a Proxy instead of the POJO which is cluster aware (using RMI maybe) but I see no benefit, only complexity....

                          Comment


                          • #14
                            Originally posted by gregturn View Post
                            You are not going to tell me that having multiple servers, providing the same stateless service, is bad, are you?
                            Except that overhead of remote calls will eliminate any benefit you can achieve from this solution very quickly.

                            Comment


                            • #15
                              Originally posted by gregturn View Post
                              You are not going to tell me that having multiple servers, providing the same stateless service, is bad, are you?
                              You guys are dancing around a few different concepts I think... I don't think that going through a load balancer would decrease the performance of an application and of a stateless business layer (assuming that there's already a physical business layer), nevertheless the first rule of distributed computing applies: Don't distribute your objects (unless you have to)! Obviously failover is a good enough reason to have a cold or hot backup server but that doesn't mean that a physical business layer is always the best thing.

                              - Yagiz -
                              http://blog.decaresystems.ie (Shameless "company blog link" )

                              Comment

                              Working...
                              X