1 Reply Latest reply on Dec 15, 2006 3:22 PM by Brian Stansberry

    Clustering local interfaces.

    Sajid Moinuddin Newbie

      Hi all,
      We have developed an web based application on a single jboss server. We have stateful session bean/ stateless session bean/ entity beans. However, Since all the clients of ejb are in the same container, we have implemented the whole module using local interface. None of our components so far has remote interface. Now, we want to cluster the system. bypassing the ejb clustering/stateful session bean clustering is not an option for us.
      Now, My question is can we cluster the whole system with the local interfaces so far we have used? We want session state replication of stateful session beans. I want to understand the whole picture before rushing into any perticular solution. any help will be much appriciated.

        • 1. Re: Clustering local interfaces.
          Brian Stansberry Master

          I'll preface this all by saying you're going to have to try it out; I'm pretty sure most of our unit tests involve EJBs with remote interfaces.

          Clustering an EJB does the following for you:

          1) On the client side:

          Client gets a smart proxy that automatically tracks cluster topology, load balances calls around the cluster, and can fail over to another server if it detects certain kinds of failures during a call.

          (Note the client can be inside the appserver with the beans; 'client' is any code that access the beans and makes calls on them.)

          2) On the server side:

          For beans with state, keeps state in sync between servers. For SFSBs that means replicating state. For entities, that means invalidating local caches if an entity is changed on another server. (For EJB3 entities it currently means replicating state; this may move to an invalidation model or to a choice.)

          OK, with all that spelled out, now to answer your question...

          The client-side benefits don't apply if you have no remote interface, since without it a client can only interact with a bean in the same jvm.

          The server side benefits do apply. For example, if the 'client' is a servlet contacting an SFSB, if you store an EJBHandle in the session and replicate the session, if the user fails over to another server, the EJBHandle can be used to retrieve the SFSB.

          SLSBs have no state, so there is no benefit to marking an SLSB with no remote interface as clustered.