Implementation of CORBA object lifecycle and memory management

After classifying them according to the state of the servo objects, the classification of CORBA objects is now defined based on memory management. Obviously, this discussion is closely related to the life cycle of the servo object. This focuses on classification, so simply discuss memory management issues and introduce a common management model below.

1. Static CORBA Object

A static object is a CORBA object that exists throughout the life of the system. Typically, these objects are component entry points for example, the CORBA naming service must provide a naming context to create a new naming hierarchy. This root naming context can be categorized as static because it always exists. From the memory management point of view, the implementation of static objects is very simple. Normally, a static object can be implemented by instantiating the servo object in the server mainline and binding it directly to the associated CORBA object (that is, early binding).

2. Transient CORBA Object

A transient CORBA object is not associated with any persistent state-it is indeed transient. Typically, a transient CORBA object is bound to a stateful servo object, where the state of the object is only contained by the servo object. Unfortunately, this means that the life cycle of the transient CORBA object is tightly bound to the life cycle of the Servo object: the creation of a transient CORBA object inevitably results in immediate activation of the servo object to implement the object. On the other hand, the destruction of the servo object immediately causes the deletion of the associated CORBA object, because all States disappear with the servo object.

An appropriate example of a transient object is an iterator, which allows the user to repeatedly view the query's result collection. The iterator object is not bound to any persistent state because the query result is usually transient. It can be difficult to find a good memory management strategy for a transient CORBA object.

3. Persistent CORBA Object

Finally, persistent CORBA objects are associated with other persistent states and are maintained by the data management system. This enables users to apply a very flexible memory management policy to the implementation of these objects, because we can use late binding to dynamically activate and freeze the servo objects.

4. Servo Object Pool Mode

The classification of CORBA object shows that different objects have different requirements from the view of memory management. The servo object pooling model defines a common framework for servo object management. Its basic idea is to include a pool manager to manage the pool where the active servo object resides. Each servo object is associated with an expulsion policy. This policy describes when a servo object is evicted. The pool manager has two roles: a cage and an expulsion device. The retention device guarantees that the object exists when needed. For example, a transient object cannot be recreated, so it must remain in the client's request for it to complete. The expulsion device must ensure that the servo object is often driven out, in order to avoid unnecessary resource consumption.