Java Reference
In-Depth Information
more likely than an EJB request to get access to the CPU. In effect, the servlet is given a 3x
There are limitations to this. The separate pools cannot be set so that an EJB request would
run only if there were no servlet requests pending. As long as there are threads in the EJB
thread pool, those threads will compete equally for the CPU, no matter how busy the servlet
thread pool is.
Similarly, care should be taken not to throttle a particular pool below the amount of work ex-
pected when the server is otherwise idle. If the JMS pool is sized to have only three threads
on the four-CPU machine, then it won't use all of the available CPU if there are only JMS re-
quests to process. To compensate for that, the size of all pools can be increased proportion-
ally, but then you run the risk of oversaturating the machine by trying to run too many
Hence, this kind of tuning is quite delicate and depends on having a good model of the traffic
into your application server. It is used to get that last few percentage points of performance
from your application.
Enterprise Java Session Beans
This section looks into the performance of EJB 3.0 session beans. Java EE containers man-
age the lifecycle of an EJB in a very specific way; the guidelines in this section can help
make sure that lifecycle management doesn't impact the application's performance.
Tuning EJB Pools
EJBs are stored in object pools because they can be quite expensive to construct (and des-
troy). Without pooling, a call to an EJB would involve these steps:
▪ Create the EJB object
▪ Process annotations and inject any resource dependencies into the new EJB
▪ Call any method annotated with @PostConstruct
▪ For stateful beans, call any method annotated with @Init , or call the ejbCreate() meth-
▪ Execute the business method
Search WWH ::

Custom Search