Java Tutorial - Java Scipt :
Sharing the JVM with the Servlet Container
EJB containers are just one layer in the J2EE application server stack. Quite often EJB containers will also include a servlet container. The reasons for this marriage are better performance and increased convenience. Examples of EJB containers bundled with a servlet container include commercial products such as the WebLogic application server as well as open source products such as JBoss. JBoss is actually offered in two different bundles:
· The default bundle with the Jetty servlet container integrated with it
· A bundle featuring JBoss integrated with Apache Tomcat
The choice of bundles preserves the developer’s freedom to choose a servlet container, while maintaining the benefits of a shared JVM. It also highlights an important point: You can integrate different servlet containers for use with an EJB container in the same JVM. Although the J2EE specification does not mandate this, some EJB containers and servlet containers have worked out the necessary API hooks to allow for this customization. Sharing a JVM improves performance by reducing the cost of communication. These are significant improvements, too, on the scale of an order of magnitude. For example, an EJB invocation by a servlet across separate physical machines will require network resources such as a socket, incur marshalling and demarshalling costs, and cross through many more abstraction layers. By comparison, some EJB containers can optimize a shared JVM EJB invocation to a level of performance roughly equivalent to that of a method call. Having a shared JVM also makes development tasks more convenient. For example
· There’s no need to start up separate processes for the EJB container and the servlet container.
· There are fewer configuration files to adjust in order to get the two to talk to one another.
· Tracing a servlet to EJB call is easy with a shared JVM, whereas trying to debug a call that crosses JVMs is nigh impossible. Of course, sharing is not without its problems:
· The fate of the EJB container becomes tied with that of the servlet container. Should one cause an instability or crash the JVM, the other will suffer as well.
· Sharing a JVM limits the horizontal and vertical scalability of the EJB and servlet container to exactly one machine. This limit is acceptable as long as a single machine can handle the peak load, but with larger applications, it’s just not possible.
· Operating system limits now apply to the combined requirements of the two. For example, if process has a limit of 16 semaphores, that must now be split between the EJB container and the servlet container. Many systems will manage multiple servlet and EJB processes better than a single gargantuan process. Of course, through proper tuning of the operating system and JVM parameters, this drawback can be mitigated.
In general, the drawbacks are not too worrisome. However, when the application needs to scale out to multiple machines, sharing the JVM becomes impossible to do. Sharing a JVM on a single machine is often ideal for development and prototyping purposes; however, this decision needs to be made separately for deployment systems. This topic is covered in more detail in
