When you bind an object to a JNDI context, it either gets serialized, or if it is Referenceable, its reference is serialized. Naturally, when you lookup the object, the object is deserialized, or recreated from the reference's object factory (this should be particularly obvious in the HA-JNDI case). Any mutations to an object are not automatically reflected in the JNDI directory, since it only stores serialized forms. To make a change visible to other nodes, you'll have to rebind the object after modifying it.
Thanks for your answer .
If we focus in JNDI definition (java 1.3 and later), I am supposed to be able to run the remote method in the remote JVM. Actually that is the procedure in a WebLogic server: I can get a JNDI object from a remote node and if I change its content, another client in the same node where JNDI object resides can see such change without any rebind. I have done that with that result, but in JBOSS I don't have it.
Do I have to use clustered stateful EJB to get that behaviour?
In WebLogic I have implemented a JNDI object to synchronize operations in cluster nodes, but that mechanism is no longer valid in JBOSS at the moment...
Well, I finally found a solution after so many days of intense investigation: a clustered @service bean deployed in the "deploy-hasingleton" directory. So I have to transform my JNDI into that kind of bean. Don't have to rebind, don't have to worry about failure and all JVM in the cluster can synchronize each-other.