METHOD OF REMOVING AN INSTANCE OF A STATEFUL SESSION BEAN

Abstract

A method of removing an instance of a stateful session bean from a passive state, and a computer program product to execute this method. An event initiates the removal of said instance of the SFSB from the passive state to a does-not-exist state. Upon that event, a function of a container managing the SFSB is triggered. Said function handles the release of external state objects associated with the instance of the SFSB upon removing the instance of the SFSB. In one preferred embodiment of the method introducing a new type of callback method, said instance of the SFSB is partially reactivated, after calling said new type of callback method on said instance of the SFSB, by setting said instance of the SFSB in a near remove state between the passive state and the does-not-exist state.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

These as well as further features and advantages of the invention will be better appreciated by reading the following detailed description of presently preferred exemplary embodiments taken in conjunction with accompanying drawings of which:

FIG. 1 is a block diagram showing a detail of the lifecycle of a SFSB according to an embodiment of the invention.

FIG. 2 is a block diagram showing a detail of the lifecycle of a SFSB according to another embodiment of the invention.

FIG. 3 is a block diagram showing a detail of the lifecycle of a SFSB according to still another embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the three main stages in the life cycle of a SFSB, the does-not-exist state 10, the method ready state 11, and the passive state 12. In the does-not-exist state 10, the SFSB does not have an instance in the memory. In this state 10, the SFSB has not been instantiated.

When a client obtains a reference to a SFSB instance through dependency injection or JNDI lookup, or when the client invokes a create<Method> method on the SFSB's home interface, a SFSB instance's life starts (JNDI=Java Naming and Directory Interface). This causes the container to invoke newInstance on the SFSB class to create a new SFSB instance. After a couple of further steps 101 by the container known in the prior art, the instance of the SFSB is in the method ready state 11.

In the method ready state 11, the SFSB has an instance in the memory of the EJB container and it is ready to serve the client. One instance of the Stateful Session Bean serves only one client. From the method ready state 11, the instance of the SFSB can be moved 104 into the does-not-exist state 10 by a remove method or a timeout. For example, a remove method is executed when the container calls the ejbRemove or PreDestroy callback.

If the container's caching algorithm decides that the SFSB instance should be evicted from memory, the container issues ejbPassivate on the SFSB instance and the SFSB instance is passivated by moving 102 the SFSB instance from the method ready state 11 to the passive state 12.

In the passive state 12 the SFSB instance is passivated to conserve the resource. The passivate method is called before the SFSB instance enters the “passive” state. The SFSB instance should release any resources that it can re-acquire later in the ejbActivate( ) method. After the passivate method completes, the SFSB instance must be in a state that allows the container to use the Java Serialization protocol to externalize and store away the SFSB instance's state. The ejbRemove callback method or a timeout moves the bean into the Does Not Exist stage.

According to a first embodiment of the invention described in FIG. 1, the function of the container is enforced to always call the ejbRemove or PreDestroy method when the container decides to remove the SFSB instance from the passive state 12 to the does-not-exist state 10. Preferably, the function of the container first brings 103 the SFSB instance from the passive state 12 to the method ready state 11, by calling an ejbActivate method. By activating the SFSB instance again, the SFSB will/could reclaim (external) resources, which will be freed again almost immediately, because the bean will be “removed”. Calling, by the container, the ejbRemove or PreDestroy method on the SFSB instance in the method ready state 11 causes the SFSB instance to be moved 104 from the method ready state 11 to the does-not-exist state 10.

By virtue of the fact that the SFSB instance is not removed from the passive state 12 in a direct way but via the method ready state 11, the instance of the SFSB can be informed about its nearby removal. Likewise, the conversational state associated with the SFSB can be notified about the imminent invalidity of the SFSB. Thus, there is a possibility for the clean-up of external states associated with the SFSB instance before the SFSB instance does not exist any more.

FIG. 2 is related to another embodiment of the invention. FIG. 2 shows—in analogy to the situation of FIG. 1—again the three main stages in the life cycle of a SFSB, the does-not-exist state 20, the method ready state 21, and the passive state 22.

At the generation step 201 of a SFSB instance, it is checked and defined, respectively, whether the SFSB instance needs the behaviour as given above in the embodiment of the invention related to FIG. 1. That means that for each SFSB instance that is created, an indicator is set which indicates if the created SFSB instance, while in the passive state 22, must be activated before being removed or not. In FIG. 2, a storage device 25 is shown where said indicator may be stored. This storage device 25 may be memory space in a meta-data field associated with a SFSB. Preferably, said storage device 25 is a deployment descriptor of the SFSB and said indicator is a flag in said deployment descriptor of the SFSB.

Then, the SFSB instance may be passivated and moved 202 from the method ready state 21 to the passive state 22, as described above with reference to FIG. 1.

When the container decides to remove the passivated SFSB instance from the passive state 22, this may proceed in either of two alternative ways.

The first alternative is that, as is shown in FIG. 2, the SFSB instance for which said flag is set is first activated 203 from the passive state 22 to the method ready state 21. By activating the SFSB instance again, the SFSB instance will/could reclaim (external) resources, which will be freed again almost immediately, because the SFSB instance will be “removed”. While the SFSB instance is in the method ready state 21, the container calls on the SFSB instance the ejbRemove or PreDestroy method, which causes the SFSB instance to be moved 204 from the method ready state 21 to the does-not-exist state 20.

By virtue of the fact that a SFSB instance is not necessarily removed from the passive state 22 in a direct way but that it may be removed via the method ready state 21, the instance of the SFSB can be informed about its nearby removal. Likewise, the conversational state associated with the SFSB can be notified about the imminent invalidity of the SFSB. Thus, there is a possibility—for selectively defined SFSBs which may need this possibility—for the clean-up of external states associated with the SFSB instance before the SFSB instance does not exist any more.

However, not every SFSB may need this re-activation to the method ready state 11 or 21 before being moved into the does-not-exist state 10 or 20. For these SFSB instances, the second alternative is advantageous. The second alternative is that the SFSB instance for which said flag is not set is directly removed 205 from the passive state 22 to the does-not-exist state 20.

FIG. 3 is related to still another embodiment of the invention. FIG. 3 shows—in analogy to the situation of FIG. 1 and FIG. 2—again the three main stages in the life cycle of a SFSB, the does-not-exist state 30, the method ready state 31, and the passive state 32.

The basic idea of this embodiment is to modify the SFSB lifecycle, as presented in FIG. 3, for SFSBs still having an external state associated thereto, in the sense that it makes it possible a callback function to be called by the container even if the SFSB is in the passive state 32 and needs to be removed from disk storage.

Basically, the embodiment according to FIG. 3 introduces a call back function that may be called when the container needs to remove the SFSB. Only the container knows and decides when to remove a SFSB from passive state 32. The present embodiment of the invention provides a new type of callback method. If the SFSB has provided this method, the container calls this method upon removing a bean from the passive state 32.

This name of this new type of callback function may be, e.g., ejbRemoveFromPassive or PreDestroyFromPassive.

Let us assume that a SFSB instance has been generated 301 and, after the generation 301 of its method ready state 31, moved 302 from the method ready state 31 into the passive state 32. If the container decides that the SFSB instance should be removed from the passive state 32, the function of the container checks whether the SFSB instance has provided the new callback method. Each SFSB may have meta-data associated with it from which the information can be retrieved whether the SFSB supports the new callback method.

If so, the function of the container calls the new callback method on the SFSB instance. The SFSB instance, called upon by this new callback method, is put 303 into a new state 33 where it does not re-claim resources, though. Preferably, the new state 33 may represent a state where the SFSB instance and the external resources associated with the SFSB instance are semi-activated. From this new state 33, the SFSB instance is then removed, i.e., moved 304 into the does-not-exist state 30. The bean provider can implement this callback method in such a way to avoid unnecessary external resource reservations, yet it is possible to indicate to external states to clean up their states as well. Thus, resources associated with the SFSB instance to be removed and not needed any more can be released in due time.

By calling the new type of callback method, the instance of the SFSB is informed about its nearby removal. Likewise, the conversational state associated with the SFSB can be notified about the imminent invalidity of the SFSB, although the SFSB instance has not been re-activated in the traditional manner, i.e., by moving the SFSB instance to the method ready state.

However, if the examination of the meta-data of the SFSB show that the SFSB does not support the new callback method, the SFSB instance is removed from the passive state in a process 305 without the near remove state 33, e.g., in a remove method 305 known from prior art. If the new callback method is not supported also any of the other remove methods described above may be used to remove the SFSB instance from the passive state 32.

Claims

1. A method of removing an instance of a stateful session bean from a passive state, whereby the method comprises the steps of: initiating, by an event, the removal of said instance of the SFSB from the passive state to a does-not-exist state; andtriggering upon that event a function of a container managing the SFSB wherein said function handles the release of external state objects associated with the instance of the SFSB upon removing the instance of the SFSB.

2. The method of claim 1, wherein the method comprises the steps of: reactivating, by said function, said instance of the SFSB from the passive state to an active state;reclaiming, by the instance of the SFSB upon reactivation, resources;calling, by said container, a callback method that releases external state objects associated with the instance of the SFSB; andremoving the instance of the SFSB from the active state to the does-not-exist state.

3. The method of claim 1, wherein the method comprises the steps of: storing an indicator that selectively indicates whether a respective instance of the SFSB needs to be reactivated from the passive state to an active state for the release of the external state objects associated with the instance of the SFSB upon removing the instance of the SFSB;checking, by said function, whether the instance of the SFSB to be removed carries said indicator;if said instance of the SFSB carries said indicator, reactivating the instance of the SFSB from the passive state to the active state and releasing the external state objects associated with the instance of the SFSB; andif said instance of the SFSB does not carry said indicator, directly removing the instance of the SFSB from the passive state to the does-not-exist state.

4. The method of claim 3, wherein said indicator is a flag in a deployment descriptor of the SFSB.

5. The method of claim 1, wherein the method comprises the steps of: providing a new type of callback method within the SFSB, said new type of callback method releasing the external state objects associated with the instance of the SFSB upon removing the instance of the SFSB; andremoving by the container the instance of the SFSB from the passive state by means of calling, by said function of the container, said new type of callback method.

6. The method of claim 5, wherein the method comprises the steps of: checking, by said function of the container, whether said instance of the SFSB has provided said new type of callback method;if the instance of the SFSB has provided said new type of callback method, calling said new type of callback method on said instance of the SFSB; andif the instance of the SFSB has not provided said new type of callback method, removing the instance of the SFSB from the passive state.

7. The method of claim 5, wherein said function recognizes from meta-data associated with the SFSB whether the SFSB supports said new type of callback method.

8. The method of claim 5, wherein the method comprises the step of: partially reactivating, after calling said new type of callback method on said instance of the SFSB, said instance of the SFSB by setting said instance of the SFSB in a near remove state between the passive state and the does-not-exist state.

9. The method of claim 5, wherein the method comprises the step of: indicating, by calling said new type of callback method, external state information for clean-up of the external state objects.

10. A computer program product adapted to perform the method of claim 1 when executed on a computer.