Inclusion into the Interceptors chain
Every modification done are sent to all connected replicas. This is done when the modifications are validated locally, and only if everything went right.
Interceptor chain description
The following schema shows how the interceptor chain is working.
Here, a request is injected in the topmost interceptor, which will handle it and if needed, do an associated action, before passing the request to the next interecptor, and so on until it reach the nexus, where this object is managed.
If we have an exception or an error condition in ant interceptor, then we go back to the chain either by throwing and exception, or simply by returning.
An interceptor can be a pass-through for an incoming request (doing nothing with it)
Existing interceptors
We have more than one chain of interceptors, to cover all the different operations
Using an interceptor for Mitosis
The idea is to use an interceptor when a request (add, mod, del, ...) is sent to the server. It should only send a message to other replicas only if everything went fine for all other interceptor. This will then be a passthrough interceptor for the incoming request, which will do all the work at the end.
Potential problems
The main problem is that we should guarantee an ACID transaction , which means that we must set a lock on the object until it has been managed by the nexus.
Add Entry operation
Suppose that we add an entry Ei in the serveur Si at time Ti, and that we have to propagate this change to server Sk.
This operation will have to deal with those followong cases :
- The server Sk is not responding
- The entry Ei already exist in serveur Sk
- The entry Ei does not exist in serveur Sk
- The entry Ei has already been created on another server Sn at Tx where Tx < Ti
- The entry Ei has been created on another server Sn at Tx where Tx > Ti
The third case is the most general case.