actor
An Actor that wraps around a NumberPool and regulates access to it.
Wrapping around the pool like this forces a FIFO order to requests for numbers from the pool.
A message for accepting object-number registration requests.
The callback is actually an ActorRef to which a RegisterSuccess message or a RegisterFailure message is sent.
A message for accepting object-number registration requests.
The callback is actually an ActorRef to which a RegisterSuccess message or a RegisterFailure message is sent.
This is as opposed to what a "callback" is normally - a function.
the mandatory object
the optional name of the number pool to which this object is registered
the optional number pre-selected for registering this object
the optional custom callback for the messages from the success or failure conditions
An Actor that wraps around converted NumberPools and synchronizes a portion of the number registration process.
An Actor that wraps around converted NumberPools and synchronizes a portion of the number registration process.
The ultimate goal is to manage a coherent group of unique identifiers for a given "region" (Zone).
Both parts of the UID system sit atop the Zone for easy external access.
The plain part - the NumberPoolHub here - is used for low-priority requests such as checking for existing associations.
This Actor is the involved portion that paces registration and unregistration.
A four part process is used for object registration tasks.
First, the requested NumberPool is located among the list of known NumberPools.
Second, an asynchronous request is sent to that pool to retrieve a number.
(Only any number. Only a failing case allows for selection of a specific number.)
Third, the asynchronous request returns and the original information about the request is recovered.
Fourth, both sides of the contract are completed by the object being assigned the number and
the underlying "number source" is made to remember an association between the object and the number.
Short circuits and recoveries as available on all steps though reporting is split between logging and callbacks.
The process of removing the association between a number and object (unregistering) is a similar four part process.
The important relationship between this Actor and the Map of NumberPoolActors is an "gate."
A single Map is constructed and shared between multiple entry points to the UID system where requests are messaged.
Multiple entry points send messages to the same NumberPool.
That NumberPool deals with the messages one at a time and sends reply to each entry point that communicated with it.
This process is almost as fast as the process of the NumberPool selecting a number.
(At least, both should be fast.)
A message for accepting object-number unregistration requests.
A message for accepting object-number unregistration requests.
When given to a number pool (NumberPoolAccessorActor), that Actor assumes itself to have the object.
When given to a hub object (NumberPoolHubActor), it will attempt to determine which pool currently has the object.
The callback is actually an ActorRef to which a RegisterSuccess message or a RegisterFailure message is sent.
This is as opposed to what a "callback" is normally - a function.
the mandatory object
the optional custom callback for the messages from the success or failure conditions
An
Actorthat wraps around aNumberPooland regulates access to it.Wrapping around the pool like this forces a FIFO order to requests for numbers from the pool. This synchronization only lasts as long as this
Actoris the only one for the given pool. In the distribution of globaly unique identifiers, this is extremely important.NumberPools are used as the primary determination of whether a number is available at any given moment. The categorization of the pool is also important, though for a contextually-sensitive reason.