Pooling of EJBObject for SessionBean

[Jun Inamori]

Hi, According to: 6.8 Stateless session beans of EJB Spec 1.1, 'remove()' on the EJBObject has nothing to do with 'ejbRemove()' on the SessionBean instance. (See Figure 15 and Figure 17.) How should we, as the Container Provider, implement the EJBObject for the SessionBean? It is safe to invoke 'ejbRemove()' on the SessionBean instance at the last stage, if 'ejbRemove()' is not called yet, isn't it? If it is true, we must know: 1. When is 'the last stage' of the SessionBean instance? 2. The list of the SessionBean instances which are not invoked 'ejbRemove()' yet. As for 1, one possible case is that the client discards the reference to the EJBObject, which means no farther remote methods will be invoked on such as EJBObject. At this time, we can (or should) invoke 'ejbRemove()' on the SessionBean instance corresponding to the EJBObject (if it is not called yet). If our EJBObject implements 'Unreferenced' interface, it can be notified when some time expires after un-referenced by the client. Another case is when the server is going to shutdown. At the time the server is shutdown, we can (or should) invoke 'ejbRemove()' on the SessionBean instance corresponding to the EJBObject (if it is not called yet). As for 2, we can keep track of the EJBObject by holding them in two instances of Vector, one is for the EJBObject now referenced, and another is for already un-referenced. Among the EJBObject which are now referenced, we can find the ones whose SessionBean instances are not invoked 'ejbRemove()' yet. It looks like this: EJBHome.create() --> EJBObject.newInstance() --> Vector for referenced --> EJBObject.unreferenced() --> Vector for un-referenced The strategy above also gives us another advantage. We can pool the EJBObject for the SessionBean. The current implementation of EJBHome always creates the new instance of EJBObject. But now, our EJBHome can re-use the EJBObject kept in the un-referenced pool. While 'ejbRemove()' is not the serious problem, pooling EJBObject will result in the performance improvement. In addition, this can be the starting point for the pooling mechanism of the SessionBean instances. Assuming that above is true, I've implemented the patch for JOnAS2.0 . I attached the source code to this mail. After extracted, you will find my modified source files under the directory of 'modified_src'. The code fragments between: //Start:Jun Inamori (For SessionBean.ejbRemove()) //End:Jun Inamori (For SessionBean.ejbRemove()) are related ones. -- Happy Java programming! Jun Inamori OOP-Reserch E-mail: [EMAIL PROTECTED] URL: http://www.oop-reserch.com

jonas_patch.zip

S/MIME Cryptographic Signature