An Algorithm for Execution of Local and Global Operations 

Use

This document discusses the following operation example: bind(String name, Object object). First, in the ClientContext, the object parameter is serialized (if it is possible) and the byte array is sent to the ServerContext, where the type and correctness of the operation are evaluated:

·        if the operation is local – the object is put against the object name in the naming storage.

·        if the operation is global – the object is put against the object name in the naming storage. Messages with the following information are sent to all servers in the cluster: the ID, name and the byte array representing the object, a byte parameter that shows whether the object is remote or not, and the name of the container in which the object has to be placed (this name is unique in the cluster and shows the full path from the root context of the naming system to the requested context). The sender server does not wait to receive answers from the other servers whether the bind operation is performed successfully.

When a new server is connected to the cluster, it sends a message with a specific ID via the MessageContext to an arbitrary server with a request for information about all global objects and contexts. This message “arrives” in the CacheCommunicatorImpl.receive (…) method of the receiver server and makes a “call” to the replicateAll (…) method of the JNDIMemoryImpl. The naming tree is recursively searched for global objects and contexts and, if any are found, they are sent as messages with all additional information to the server from which the request has been sent. The other server receives the messages and executes the operations locally. If the container in which the global object must be placed does not exist, it is created and the object is put in it. If a part of the contexts path (from the root context to the context,) in which the object must be placed does not exist, all missing intermediate contexts from the path are created. The names of the contexts are taken from the name of the container in which the object has to be placed – it contains the whole path. No response is returned to the server that sends the messages whether the replication is executed correctly or not.

If any exceptions occur during the object serialization, the object is put in an LROTable and is treated as non-serializable.

In a global bind operation of a Remote object, the type of the operation is REMOTE_REPLICATED_OPERATION. Before each lookup operation a check is made whether the looked up object is a global remote one:

·        If the object is a global remote one – a check is made whether the server on which this object was initially bound (and later replicated to all other elements) is still in the cluster (has not been shut down or crushed):

¡        If so, the object is returned as a result from the operation.

¡        If not, the object is deleted from the HashTable of the Container and a message is sent to all other servers to do the same.

·        If the object is not a global remote one – the object is returned as a result from the operation.

Internal Naming Structure