Instance pooling in EJB

The concept of pooling resources is nothing new. It's common to pool database connections so that the business objects in the system can share database access. This trick reduces the number of database connections needed, which reduces resource consumption and increases throughput. The J2EE Connector Architecture (J2eeCA) is frequently the mechanism employed by EJB containers when pooling connections to databases and other resources, and is covered a little later. Most EJB containers also apply resource pooling to server-side components; this technique is called instance pooling. Instance pooling reduces the number of component instances—and therefore resources—needed to service client requests. In general, it is also less expensive to reuse pooled instances than to create and destroy instances.

As you already know, clients of session and entity beans interact with the beans through the remote and local interfaces implemented by EJB objects. Client applications never have direct access to the actual bean. Similarly, JMS clients never interact with JMS-based message-driven beans (JMS-MDBs) directly. They send messages that are routed to the EJB container system. The EJB container then delivers these messages to the proper message-driven instance.

Instance pooling is possible because clients never access beans directly. Therefore, there's no fundamental reason to keep a separate copy of each enterprise bean for each client. The server can keep a much smaller number of enterprise beans around to do the work, reusing each enterprise bean instance to service different requests. Although this sounds like a resource drain, when done correctly, it greatly reduces the resources required to service all the client requests.

In EJB

Generally speaking the following occurs:
- upon startup the container may pre-populate the pool with some number of beans (at least one).
- if the number of concurrent requests exceeds the number of available bean instances in the pool the container may instantiate new instances, or block the requests (usually due to the pool reaching it's maximum number of instances) until a bean becomes available.
- the container may remove instances from the pool (usually due to low demand).
Keep in mind the exact method by which a container chooses to instantiate/destroy instances is left up to the container vendor.

Like all EJBs stateful session beans are pooled resources. During its lifetime a stateful session bean instance can chance identity many times.
After a stateful session bean instance has been passivated or removed, it can obtain a new identity by either creation or activation.

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com