In my http://www.madplanet.com/weblog/blog/schaefa/Madplanetcom/2007/02/22/Does... recent blog entry I discussed the topic in more details but here is my design for a HAJNDI revamp: In my view the HAJNDI tree should be populated whenever an entry is made to a JNDI server on a node in a cluster. The HAJNDI tree would cache the JNDI NameClassPair and the nodes on which it can be found but not the content of the entry. If a HAJNDI deregister the entries from this node are removed. During a lookup it would search the nodes until if can retrieve the desired objects from one node. If a node is unavailable it could be put to the back of the list. The HAJNDI list() method would return an enumeration of the cached NameClassPair without any duplication by the nodes. In the lifetime of a regular application the deployment is happening rarely but the lookup and list methods are called many times. So the overhead of publishing a JNDI binding/unbinding over the entire cluster is much smaller than the time spent on the lookups and listings. The last point here would be what happens when a node is temporarily separated from the cluster. Then a deployment could be done on this node or another node on the rest of the cluster. The only fix I see is that HAJNDI needs a way to replicate its structure with other HAJNDI servers when they are out of sync. RIght now I do not know how this can be done or what event would trigger that but it should be possible. -Andy View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020999#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...