[Java programming language only]

Managing plug-in life cycles

You can manage plug-in life cycles with specialized methods from each plug-in, which are available to be invoked at designated functional points. Both initialize and destroy methods define the life cycle of plug-ins, which are controlled by their owner objects. An owner object is the object that actually uses the given plug-in. An owner can be a grid client, server, or a backing map.

About this task

Similarly all plug-ins can implement the optional mix-in interfaces appropriate for their owner object. Any ObjectGrid plug-in can implement the optional mix-in interface ObjectGridPlugin. Any BackingMap plug-in can implement the optional mix-in interface BackingMapPlugin. The optional mix-in interfaces require implementation of several additional methods beyond the initialize() and destroy() methods for the basic plug-ins. For more information about these interfaces, see the API documentation.

When owner objects are initializing, those objects set attributes on the plug-in, then invoke the initialize method of their owned plug-ins. During the destroy cycle of owner objects, the destroy method of plug-ins are consequently invoked also. For details on the specifics of initialize and destroy methods, along with other methods capable with each plug-in, refer to the topics relevant to each plug-in.

As an example, consider a distributed environment. Both the client-side ObjectGrids and the server-side ObjectGrids can have their own plug-ins. The life cycle of a client-side ObjectGrid, and therefore, its plug-in instances are independent from all server-side ObjectGrid and plug-in instances.

In such a distributed topology, assume that you have an ObjectGrid named myGrid defined in the objectGrid.xml file and configured with a customized ObjectGridEventListener named myObjectGridEventListener. The objectGridDeployment.xml file defines the deployment policy for the myGrid ObjectGrid. Both the objectGrid.xml and objectGridDeployment.xml files are used to start container servers. During the startup of the container server, the server-side myGrid ObjectGrid instance is initialized. Meanwhile, the initialize method of the myObjectGridEventListener instance that is owned by the myObjectGrid instance is invoked. After the container server is started, your application can connect to the server-side myGrid ObjectGrid instance and obtain a client-side instance.

When obtaining the client-side myGrid ObjectGrid instance, the client-side myGrid instance goes through its own initialization cycle and invokes the initialize method of its own client-side myObjectGridEventListener instance. This client-side myObjectGridEventListener instance is independent from the server-side myObjectGridEventListener instance. Its life cycle is controlled by its owner, which is the client-side myGrid ObjectGrid instance.

If your application disconnects or destroys the client-side myGrid ObjectGrid instance, then the destroy method that belongs to the client-side myObjectGridEventListener instance is invoked automatically. However, this process has no impact on server-side myObjectGridEventListener instance. The destroy method of the server-side myObjectGridEventListener instance can only be invoked during the destroy life cycle of the server-side myGrid ObjectGrid instance, when stopping a container server. Specifically, when stopping a container server, the contained ObjectGrid instances are destroyed and the destroy method of all their owned plug-ins is invoked.

Although the previous example applies specifically to the case of a client and a server instance of an ObjectGrid, the owner of a plug-in can also be a BackingMap interface. In addition, carefully to determine your configurations for plug-ins that you might write, based on these life cycle considerations. Use the following topics to write plug-ins that provide extended life cycle management events that you can use to set up or remove resources in your environment: