Ice Notes---ice Run time in detail (ii)

Servant Locator

The function of the ASM table (Servant Activity Mapping table) is described before. But he also has some limitations, because if you're using the adapter's ASM to map ice objects to servents, there are some effects: (1) Each Ice object has a different servant representation. (2) All Servants of all ice objects are permanently out of memory. If there is a large number of servant objects, then the server will be under great pressure, perhaps not enough memory, perhaps the initialization of all servants for a long time.

1. Locator Overview

The servant locator is a local object, and we are responsible for implementing it and putting it on the rest of the object adapter. Once the adapter has a servant locator, it can query the ASM as usual and position the servant. If the corresponding servant can be found on the ASM, the request is assigned to the servant. If it is not found, the object adapter recalls the servant Locator, which provides servant for the request. The servant locator will do one thing:

--Initializes a servant and passes it to the ice run time, in which case the request is assigned to the newly instantiated servant.

The--servant locator tells Ice run time that he did not find the corresponding servant. In this case, the customer is subject to objectnotexistexception exceptions.

With this simple mechanism, our servers allow us to access an unlimited number of ice objects: The server does not have to instantiate a single servant for each existing ice object. Servers that provide database access often use the servant locator: the number of entries in the database is usually much larger than the number of entries the server can store in memory. Servers used for Process control or network management also use the servant locator often.

2. Servant Locator connector

Module Ice {

Local interface Servantlocator {

Object Locate (current curr,out localobject cookie);

Void finished (current curr,object servant,localobject cookie);

void Deactivate ();

};

};

Servantlocator is a local interface. In order to create the actual servant Locator implementation, we must define a class derived from Ice::servantlocator and implement locate,finised and deactivate operations.

Locate: Whenever a request arrives and he does not have a corresponding entry in the ASM, Ice run time calls locate.

Finished: Once the request is complete, the Ice run time calls finished to pass the servant that completes the operation, the current object of the request, and the cookie that locate created at the beginning. This means that each locate will have a corresponding finished.

Deactivate: When the object adapter to which the servant locator belongs is deactivated, the Ice run time invokes the Deactivate operation.

3. Thread guarantee for servant Locator

When necessary, we must use mutexes to protect shared data in locate and finished.

4. Registration of servant Locator

The object adapter does not automatically understand a servant locator, and we want to explicitly register the servant locator with the object adapter.

Module Ice {

Local interface Objectadapter {

// ...

void Addservantlocator (Servantlocator locator,

string category);

Servantlocator Findservantlocator (string category);

// ...

};

};

It can be seen from the top that the object adapter allows us to add and find servant locators. The following is a simple function flow diagram of the servant locator:

5. Use cookies

Sometimes, we need to pass information between locate and finished. For example, a locate implementation can pick one from a variety of database backend depending on load or availability, and the implementation of finished may need to know which database locate is using in order to perform the work properly, and after the operation call is complete, the Ice run Time will pass the value of this cookie to finished.

Cookies must derive from Ice::localobject to accommodate any state and member functions that are useful to our implementation.