Distributed Object Management

Every process keeps a single object table mapping wire representation to their concrete objects or stubs.

    HashMap objTab= new HashMap();

Invariant:

If P has a network reference of object o owned by Q, then objTab.get(o.wrep) gives the concrete object reference on Q and a unique stub on P.

When the process P has one ore more references of objects owned by Q:

There is a server connection on P for requesting methods calls from P to objects living in Q (class ServerConnection).
There is a client connection on Q for serving the methods call coming from P to objects living in Q (class ClientConnection).
There is a thread running on Q which reads the requests from the client connection with P, and dispatches them (launched by the class ClientConnection).

When sending a network reference obj:

If the object is remote, just send it. The object must be in the object table.
Otherwise, the object is local.
If object obj has not a wire representation:
- Create a wire representation: the name of the stub class is the name of the class of the concrete object plus the suffix `Stub'.
- Assign a dispatcher for deserializing remote invocations: append `Skel' to the object class and create a new object of that class.
Ensure that the mapping obj.wrep->obj belongs to the object table.

(See method sendNetObj in file Manager.java).

When receiving a wire representation wrep of an object owned by P:

If exists x such that wrep->x belongs to the object table, replace wrep by x (the referenced object may be local or remote).
Otherwise the referenced object is remote:
- Open a server connection server with the process identified by wrep.sp, if it does not exist.
- Make a stub of class wrep.stubClassName which will send its requests through server.
- Put the association wrep->stub in the object table.

(See method receiveNetObj in file Manager.java).

(class Manager).

The manager is a monitor ensuring mutual exclusion to access the object table.
The manager also processes the reception and sending of network references.
Receiving a network reference does not lock the manager to avoid bottlenecks on the manager.
Server connections are created on the background to avoid blocking a thread receiving a remote reference.
Sending a network reference asks the manager monitor, but execution time is short.

(class ServerConnection)

Remote methods can be invoked concurrently by multiple threads.
The remote invocation begins with the calling of the stub.
The stub executes the method startRemoteCall which:
- waits until the server connection be free (method take).
- locks the server connection.
- sends the wire representation of the object through the socket.
- sends an indentifier of the invoked method.
The stub sends the parameters and invokes waitRemoteRet... to flush the socket and waits for a returned value.
unlocks the server connection.

(class ClientConnection)

If the process P has network references of objects living in Q, then Q runs a thread to serve all invocations coming from P.
The thread loops executing:
- Read a network reference of a concrete object o living in Q.
- Read a method identification.
- execute o.dispatch(..., o, method-id).
If any exception is thrown by dispatch close the socket.
If the server connection finds the socket closed, it will reopen the socket later.

The first time an object is exported or imported, the manager launches a thread for accepting connections. This thread:

Opens a port for accepting socket connections.
Executes the following loop:
- Accept a new connection.
- Read an object factory of type ConnectionFactory from the new socket.
- Invoke the method factory.makeConnection(socket, ...)

The client counter part will send the appropiate serializable factory which will create the client connection.

(see method openServerSocket in file Manager.java)

Two threads can receive concurrently the same network reference: This race condition may produce two stubs for the same reference.
The manager solves this problem associating a dummy object to the received wire representation in the object table.
Placing objects in the object table will prevent them to be garbage collected.
The manager solves this problem by using a weak reference of the network object.
Concrete object having network reference may be garbage collected if not referenced locally.
The manager solves this problem placing strong references of concrete network objects when they have remote references.

When a stub is garbage collected locally, the object manager has lost any reference of the stub, so it is unable to know when a process no longer references a remote object.
The stub class solves this problem redefining the method finalize (this is called finalization in Java). The local garbage collector will invoke it automatically when it detects that the stub is no longer reachable (at most once).
A memory leakage was found that prevented the garbage collection of stubs. This bug was triggered because object streams keep a hash table with mapping for the sent/received objects. This hash table was never cleared.
Server and client connection solved this bug by resetting the object streams after executing a remote invocation.
It is very easy to miss the keyword `synchronized' on a method which requires mutual exclusion during execution.
To simplify this problem the number of classes with objects that can be invoked concurrently was minimized (only the manager, server connections and client connections are invoked concurrently).