Here a small excerpt from the book "EJB Design Patters" of Flayd Marinescu (If you do not know the book, get it!), page 94:
Home Caching & Staleness, Clustering Issues
Questions have been raised as to wheter this pattern invalidates clustering, or whether it is possible for cached EJBHomes to go stale in a clustered or nonclustered environment. The truth is that clustered servers almost always implement cluster-aware home stubs (Weblogic & Webspher, at least, take this approach), meaning that a home is not tied to a particuar server in the cluster. Servers can fail & restart, and the cached home stubs will be able to communicate with the live or restarted servers in the cluster. As for single-server deployments, again , the home stubs of majority of servers can survive redeployment and even server restarts.
However, you should verify the semantics of your particular application server and code the HomeFactory defensively if your server can allow stale homes.
The behavior of existing ejb references in the face of redeployment is not standardized.Technically, any aspect of an application can change upon redeployment, including the interfaces of its Remote EJBs, so it would not be possible to always support old references talking to the new ejbs. It's certainly possible for a particular J2EE implementation to have special support for the case where a redeployment occurred but the Remote EJB view did not, however that's not the case in SJS AS 8.x.
To add to Floyd's remarks, there's a large difference between the cluster case/server restart and redeployment.In a cluster failover situation or in the case of server restart, existing ejb references contained within other applications should continue to function, since the application containing the target ejbs can't have undergone any change.
Kenneth Saks
J2EE Team
SUN Microsystems