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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994339#3994339 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994339 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
