1 Reply Latest reply on Jun 17, 2003 4:27 PM by Kevin

    How to cluster stateful session/entity beans?

    Kevin Newbie

      We are looking into all the issues of clustering, from hardware, load balancer, etc.

      We have some very expensive cisco load balancers that indicate they are great for web stuff, with cookies etc. The problem we face is that our client applications connect directly to the EBJ services through JNDI, 1099, etc. Is there a way to keep state if we were to use statefull session beans with load balancers like they do by tracking cookies? Or does this require a special software load balancer running on a server to properly keep track of client/ejb state to pass on to the right ejb server.

      I figure we would have a single IP entrance, with a load balancer next, and at least one partition with 3 nodes clustered. We'd probably add a second partition (or more) when we are ready to scale. Each parititon will have 3 nodes clustered. Ideally, our load balancer would have to know how to 1) make sure the same client goes to the same partition, and 2), always sends the same client to the same jboss server within the same partition. However, if we do in-memory replication of ejb state, then the client should be able to go to any of the 3 nodes in the same parition. Is this possible, if so, what have some of you done in your setups?

      Also, am I correct in understanding that jboss can handle in-memory ejb (session and entity) state replication and if so, that it replicates the state every time the state of ejb changes?

        • 1. Re: How to cluster stateful session/entity beans?
          Kevin Newbie

          Sorry, left out one last question, is it possible that a DB store can be used in place of in-memory replication and that multiple partitions could all share that store, such that if an entire partition died, a user's state is still actually saved and any other partition would be able to retrieve it. If this is possible, what are the ramifications of doing it this way? Is the DB with 1000's of clients way too slow compared to in-memory replication? Obviously the DB is another single point of failure that would also have to be properly balanced with 2 db's to avoid the db going down and ALL partitions losing state.