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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...