Using the Struts Open-Source Framework

Caching on the Web Server or in Stateful Session Beans

A very common question that comes up often when building n-tiered applications is where to cache user or application data. This question can spark debate that lasts for months and has no final agreement. Developers feel very passionate about certain topics, and this is one of them. It really shouldn't be that controversial , however. There are really several options to choose from, depending on what type of information you are trying to cache. If you need to cache data for a particular user of the system, you can either cache it on the Web server or in a stateful session bean. There are a few other alternatives, but these are really the most obvious.

Follow this rule of thumb: If the data that you are trying to cache is presentation in nature, cache the information in the user session on the Web server. An example of this type of data might be what the preferred language is for the user or whether the user wants tabs at the top or along the sides of the page.

On the other hand, if the data is more business related , think about putting this data in a stateful session bean on the application tier . Examples of business data might be the user's current shopping cart or the user's latest bid for an auction. This is just a guideline, and there might be other more nonfunctional considerations that you must consider when deciding where to cache the data. For example, what if you needed to ensure a persistent shopping cart for the user in case the system crashed? In the case of a Web server failure, unless you are providing a redundant Web server session on another box, you might lose all the user's data. If you were to cache the information on the EJB server and the server crashed, you could protect yourself a little easier by writing the information to a database when it's modified. In this way, the information could be rebuilt from the database when the user logged back in. The rule of thumb is just that. You'll have to make decisions for certain aspects of the data, depending on your specific application requirements.

If the type of data is not specific to a user but is shared across all the users of the application, the question of where to cache it is a little harder. From strictly a design standpoint, you'll probably want to make it available to the enterprise beans and, therefore, you'll probably want to keep it on the application tier. However, if this data is just for read-only combo-box style choices in the Web tier, in some cases you might want to cache it on the Web server. The answer is not the same for every situation or every piece of data. The best thing to do is to be consistent, and then deal exclusively with the data if you experience performance issues accessing it.

Caution

Be careful when caching data in the session and application areas of the presentation tier. Be sure that you perform cleanup on all the data when the session times out or when the user logs out of the application. If you don't clean up the old objects, you will eventually get an Out of Memory error after all the available memory is used up.

One way to ensure that objects are cleaned up is by having all the objects placed into the session implement the HttpSessionBindingListener interface. This interfaces contains two methods : valueBound and valueUnbound . The valueBound method will be called on an instance when it is inserted into the session. The more important valueUnbound will be called when an object is unbound by a session. You can perform any cleanup for the object and any data or resources it holds in this method.