Book: JavaServer Pages™, 2nd Edition
Section: Chapter 10.  Sharing Data Between JSP Pages, Requests, and Users



10.4 Memory Usage Considerations

You should be aware that all objects you save in the application and session scopes take up memory in the server process. It's easy to calculate how much memory is used for the application scope because you have full control over the number of objects you place there. But the total number of objects in the session scope depends on the number of concurrent sessions, so in addition to the size of each object, you also need to know how many concurrent users you have and how long a session lasts. Let's look at an example.

The CartBean used in this chapter is small. It stores only references to ProductBean instances, not copies of the beans. An object reference in Java is 8 bytes, so with three products in the cart we need 24 bytes. The java.util.Vector object used to hold the references adds some overhead, say 32 bytes. All in all, we need 56 bytes per shopping cart bean with three products.

If this is a site with a modest amount of customers, you may have 10 users shopping per hour. The default timeout for a session is 30 minutes, so let's say that at any given moment, you have 10 active users and another 10 sessions that aren't active but have not timed out yet. This gives a total of 20 sessions times 56 bytes per session, a total of 1,120 bytes. In other words, roughly 1 KB -- nothing to worry about.

Now let's say your site becomes extremely popular, with 2,000 customers per hour. Using the same method to calculate the number of concurrent sessions as before, you will have 4,000 sessions at 56 bytes; a total of roughly 220 KB -- still nothing to worry about. However, if you store larger objects in each session, say the result of a database search with an average size of 10 KB, it corresponds to roughly 40 MB for 4,000 sessions. A lot more but still not extreme, at least not for a site intended to handle this amount of traffic. However, it should become apparent that with that many users, you have to be a bit careful with how you use the session scope.

Here are some things you can do to keep the memory requirements under control:

  • Place only objects that really need to be unique for each session in the session scope. In the shopping cart example, each cart contains only references to the product beans (not copies of the beans), and the catalog bean and the product beans are shared by all users.

  • Set the timeout period for sessions to a lower value than the default. If you know it's rare that your users leave the site for 30 minutes and then return, use a shorter period. You can change the timeout for all sessions in an application through the application's deployment descriptor (see Appendix F), or by calling session.setMaxInactiveInterval( ) (see Appendix D) in a custom action, bean, or servlet to change it for an individual session.

  • Provide a way to end the session explicitly. A good example is a logout function, or invalidation of the session when something is completed (for instance when an order form is submitted). In a JSP page, you can use the <ora:invalidateSession> custom action described in Chapter 12 to invalidate the session. In a servlet or other custom code, you can use the HttpSession invalidate( ) method, see Appendix D. Invalidating a session makes all objects available for garbage collection (the term used for when the Java runtime removes unused objects to conserve memory).

We have covered a lot of ground in this chapter, so lets recap the key points:

  • The scope concept gives you full control over the lifetime and reach of shared information at a convenient abstraction level. However, resist the temptation to keep too much information around in the session scope.

  • Action elements for passing control between pages, such as the standard <jsp:forward> action and the JSTL <c:redirect> action, allow you to allocate different roles to different pages, and the JSTL <c:url> action can be used to provide support for cookie-less session tracking.

The scope abstraction and the actions together make it possible to develop JSP-based applications that are easy to maintain and extend.

    [http://safari.oreilly.com/059600317X/jserverpages2-CHP-10-SECT-4]


    Copyright © 2002 O'Reilly & Associates, Inc. All rights reserved.
    1005 Gravenstein Highway North
    Sebastopol, CA 95472