EJB pooling best practices: obtain/release ejb reference?

[nic7834]

Hi all,

I am a bit confused on EJB pooling. I have a stateless session bean, local interface only. From my client, I do a JNDI lookup for this bean's local home interface and store the reference in a class-wide member variable.

My client class then has methods client.A() and client.B() corresponding to method calls sb.A() and sb.B() of the session bean.

To make use of pooling, I obtain and release the local interface to the session bean in each client method:

public void A () {
// Obtain session bean from pool.
FacadeLocal facade = facadeLocalHome.create();

// Call method A.
facade.A();

// Release session bean back to pool.
facade = null;
}

and likewise for client.B() method.

Can someone clarify if this is the correct way for pooling stateless session beans. i.e. obtain/release the local interface.

Or would it be the local home interface that I need to obtain and release in each of the methods client.A() and client.B()?

Incidentally, my session bean makes use of CMP entity beans and obtains and stores references to their local home interfaces in class wide member variables. Various methods of the session bean then use these references to create and find/select entity beans. Are there any best practices for pooling entity beans? For example, I use a finder method to obtain a collection of entity beans, then explicitly copy out the 'data' to a second collection of data objects and return this to the client. The original collection returned by the finder method falls out of scope when the method returns and releases the entity beans back their respective pools. Correct? I do need to explicitly set the collection to null, nor iterate through the collection setting the individual items to null.

Thanks all in advance for responses!

[juha]

The container is responsible for pooling instances, and will do so regardless of how the client stores the proxies to the bean (for instance, a stateless session instance is always returned back to the pool after a method invocation returns).

[nic7834]

Ahh...ok. Thanks for clarifying.

Can you please explain the situation for entity beans then?

Hypothetically, If I obtain a collection of entity beans by invoking a finder method and pass this collection all the way up the business tier to the presentation tier then am i right in that the entity bean instances are held and not returned to their pool until the collection is eventually garbage collected.

I guess this is one reason why the relevant data should be copied into a new collection of data objects with the original collection being released as soon as possible (so as to return to the pool).

Nic

[juha]

Again, what you are returning is a collection of proxies that are disconnected from the actual entity instances on the server. The server may do whatever it sees fit with the instances (cache them, or not) and what you do with your entity proxies has no relation to it.

[nic7834]

If that's the case, then can you explain if there is a need to call the bean interface remove() method at all from the client side. What will this achieve? Nothing for a stateless session bean and deleting the associated table row for an entity bean?

What should I be doing on the client side once I'm done with the bean. Call the remove() method, then set the bean variable to null? From what I understand that you are saying is I don't have to do anything at all as far as telling JBoss to release resources (i.e bean instances) because JBoss is not holding anything.

I am also using only local interfaces, so does the same apply?

Thanks again!

[darranl]

If that's the case, then can you explain if there is a need to call the bean interface remove() method at all from the client side. What will this achieve? Nothing for a stateless session bean and deleting the associated table row for an entity bean?

Calling remove gives the application server an opportunity to optimise the number of beans held in pools as it will allow it to keep track of the number of clients that could still invoke a method on the bean.

So basically to make it easier to move your application to other application servers you should call remove when you have finished with a session bean.