That is, because each application server's JNDI tree is independent, the remote proxies retrieved through JNDI are pinned to the server on which the lookup occurred. Under this scenario, if a method call to an EJB fails, the developer has to write extra code to connect to a dispatcher, obtain the address of another active server, do another JNDI lookup, and call the failed method again. The EJB proxy service ensures that each EJB request goes to an active UBS instance. This scheme adds extra latency to each request but allows automatic failover in between method calls. Centralized JNDI tree Sybase Enterprise Application Server implements a centralized JNDI tree cluster.
Name servers house the centralized JNDI tree for the cluster and keep track of which servers are up.
Upon startup, every server in the cluster binds its objects into its JNDI tree as well as all of the name servers. Getting a reference to an EJB in a centralized JNDI tree cluster is a two-step process. An IOR points to several active machines in the cluster that have the home object. Second, the client picks the first server location in the IOR and obtains the home and remote. The name servers themselves demonstrate a weakness of the centralized JNDI tree cluster.