Interface COM.ibm.jaws.mofw.Lifecycle
All Packages  Class Hierarchy  This Package  Previous  Next  Index

Interface COM.ibm.jaws.mofw.Lifecycle

public interface Lifecycle
extends Object
This interface signals to the "manager" of an object that it is interested in changes of state in its logical and physical lifecycle. Usually, this only occurs when an object allocates resources that may not otherwise be freed by the system.

For example, an object may be associated with a specific file that is created when the object is created, opened when the object is activated, closed when the object is released, and destroyed when the object is removed. The OP and SP view of remove() and release() are somewhat different.


Method Index

 o release()
Use this method to signal the release of any interest in the object, so that any resources involved in that interest may be released.
 o remove()
Use this method to signal the end of the object's life, so that all resources associated with that life can be freed.

Methods

 o release
  public abstract void release()
Use this method to signal the release of any interest in the object, so that any resources involved in that interest may be released. If delegation is used in the implementation of the object (eg, a proxy object and a server object), then each of these implementation objects may have its own implementation of this method in order to release whatever resources are appropriate at that level of delegation.

As an example, say an object is implemented by 1 proxy object per client and 1 server object. A release on a client proxy might cause the proxy to call release() on the server object prior to freeing itself. A release on the server object might decrement a reference count and a count of 0 would allow it to be deactivated from memory.

This method need not be called or implemented if resources are freed by another mechanism. As an example, say an object is implemented using a proxy object per client and a server object. For garbage collecting languages like Java, the object client need not call this method and the proxy need not implement it, because it will be collected when all references to it go away.

If an object has a BaseCollection to manage it, most of this work is done by the BaseCollection. An object need only implement this mehtod if the object itself allocates resources during activation (eg, during in its implementation of internalizeFromStream()) that might not otherwise be freed.

 o remove
  public abstract void remove()
Use this method to signal the end of the object's life, so that all resources associated with that life can be freed. If delegation is used in the implementation of the object then each of these implementation objects may have its own implementation of this method in order to call remove() on the next level of delegation prior to eliminating itself.

As an example, say an object is implemented by a proxy object and a server object. A remove() on the proxy object would typically call remove() on the server object prior to eliminating itself and any resources associated with its life. The remove() on the server object would typically release any resources involved in its life (eg, its persistent storage and other objects that it created) prior to eliminating itself.

If an object has a BaseCollection to manage it, most of this work is delegated to the BaseCollection. An object need only implement this method if the object itself allocates resources (during object creation) that might not otherwise be freed.

A Managed object can have references that span multiple server activations, so an explicit remove() is required to end its life. After remove() has been called on an object, further references may throw an InvalidReferenceException.


All Packages  Class Hierarchy  This Package  Previous  Next  Index