A Single Java Virtual Machine Most servlet engines
A Single Java Virtual Machine Most servlet engines want to execute all servlets in a single JVM. Where that JVM itself executes can differ depending on the server, though. With a server written in Java, such as the Java Web Server, the server itself can execute inside a JVM right alongside its servlets. With a single-process, multithreaded web server written in another language, the JVM can often be embedded inside the server process. Having the JVM be part of the server process maximizes performance because a servlet becomes, in a sense, just another low-level server API extension. Such a server can invoke a servlet with a lightweight context switch and can provide information about requests through direct method invocations. A multiprocess web server (which runs several processes to handle requests) doesn’t really have the choice to embed a JVM directly in its process because there is no one process. This kind of server usually runs an external JVM that its processes can share. With this approach, each servlet access involves a heavyweight context switch reminiscent of FastCGI. All the servlets, however, still share the same external process. Fortunately, from the perspective of the servlet (and thus from your perspective, as a servlet author), the server’s implementation doesn’t really matter because the server always behaves the same way. Instance Persistence We said above that servlets persist between requests as object instances. In other words, at the time the code for a servlet is loaded, the server creates a single class instance. That single instance handles every request made of the servlet. This improves performance in three ways: It keeps the memory footprint small. It eliminates the object creation overhead that would otherwise be necessary to create a new servlet object. A servlet can be already loaded in a virtual machine when a request comes in, letting it begin executing right away. It enables persistence. A servlet can have already loaded anything it’s likely to need during the handling of a request. For example, a database connection can be opened once and used repeatedly thereafter. It can even be used by a group of servlets. Another example is a shopping cart servlet that loads in memory the price list along with information about its recently connected clients. Yet another servlet may choose to cache entire pages of output to save time if it receives the same request again. Not only do servlets persist between requests, but so do any threads created by servlets. This perhaps isn’t useful for the run-of-the-mill servlet, but it opens up some interesting possibilities. Consider the situation where one background thread performs some calculation while other threads display the latest results. It’s quite similar to an animation applet where one thread changes the picture and another one paints the display. A Simple Counter To demonstrate the servlet life cycle, we’ll begin with a simple example. Example 3-1 shows a servlet that counts and displays the number of times it has been accessed. For simplicity’s sake, it outputs plain text. Example 3-1. A simple counter
Hint: This post is supported by Gama web hosting php services