I am wondering conceptually how load-balancing works on the EJB-level (not web session replication) with Java EE containers like Glassfish. From what I have gleaned your remote interface is a proxy that delegates your call to one of many servers you may have in an environment.
If things fail are they supposed to be able to “finish” on another server? I want to understand the basic theory behind this load balancing, why is it better than a bunch of servers all running a plain web application with session affinity on a load-balancer?
You are right. In Glassfish, the initial lookup will try to contact one of the server listed in the
jndi.propertiesfile. The server then know all the other node in the cluster that will be used for round robin. The remote reference (proxy) will do that for you transparently. Theoretically nodes can be added/removed from the cluster dynamically. See Glassfish RMI-IIOP load balancing and fail-over.If the bean is stateless, you don’t even need any kind of affinity and the request can be processed on any node. Each remote reference act as a load balancer on its own.
If the bean is statefull, it’s more hairy. The cluster will try to maintain 2 replica of the bean. And the request are dispatched against these two replica. If one of the node crashes, the cluster will recreate another replica until the node is back — It’s indeed similar to HTTP session replication with session affinity.
But on the contrary to a web server, bean are transactional components. So if an exception occurs, the transaction is rolled back and the stateful bean is invalidated because its state may not be consistent any longer.
As pointed out by Pascal, there is some kind of fail-over for certain kind of failure. I the node is not available, the request can re-routed to another node. But if the node fails while the request is processed, I don’t know whether it can resubmit it somewhere else.
If you want to know more, I suggest you read Guide to GlassFish High Availability and Cluster Support in Glassfish.