Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Servlets and JSPs
Although there are individual specifications for both Servlets and JavaServer Pages, the end result of both is a Servlet class loaded in memory; JSPs are translated from a JSP to a Servlet Java file, compiled to a class file, and finally loaded into memory. Servlets and JSPs do not maintain state between requests, so application servers pool them. So you can tune the pool size and the number of Servlets that are preloaded into the pools.
Because JSPs go through the translation and compilation step prior to being loaded into memory, most application servers provide a mechanism by which you can precompile your JSPs before you deploy them. This removes the delay that end-users would experience the first time a JSP is loaded.
Servlets (and JSPs) are required to maintain four different scopes, or areas of memory that data can be stored in:
Page: Data stored here exists for the context of a single page.
Request: Data stored here exists for the duration of a request (it is passed from Servlet to Servlet, JSP to JSP, until a response is sent back to the caller).
Session: Data stored here exists for the duration of a user's session (it exists through multiple requests until it is explicitly removed or it times out).
Application: Data stored here is global to all Servlets and JSPs in your application until it is explicitly removed or until the Servlet container is restarted.
As a programmer, the choice of where to store data is a very important one that will impact the overall memory footprint of your application. The greatest impact, however, is the session scope: The amount of data that you store in here is multiplied for each concurrent user. If you store 10 kilobytes of data in your session scope for each user and you have 500 users, the net impact is 5MB. 5MB might not kill your application, but consider all 500 users going away and 500 more come. If you do not "clean up" after the users that left, you now are using 10MB, and so on. HTTP is a stateless protocol, meaning that the client connects to the server, makes a request, the server responds, and the connection is terminated. The application server then cannot know when a user decides to leave its site and terminate the session. The mechanism that application servers employ, therefore, is a session timeout; this defines the amount of time that a session object will live without being accessed before it is reclaimed. The session timeout that you choose will be dependent on your application, your users, and the amount of memory you are willing to set aside to maintain these sessions. You do not want to interrupt a slow user and make him restart his transaction, but you do not want to drain your system resources with a timeout that is any longer than is necessary.