[ Team LiB ] Previous Section Next Section

Choosing the Right Session Mechanism

It is typical when using JSPs to maintain some client information or other data caches across multiple JSP invocations. There are several stores that are available for storing information that needs to be maintained across a request-response cycle. These include the following:

  • HTTP Session— This data store is provided by the Servlet API. This is generally a good idea from a performance standpoint. The data is stored on the server, and only a session ID needs to be maintained over the network (generally using the URL rewriting method).

  • Hidden fields— Developers sometimes use hidden HTML form fields on the JavaServer Page to maintain information. The use of hidden fields is slow and limited to a maximum size of an HTTP get or post.

  • Cookies— Browser-based cookies are also used to store session information. Cookies are relatively slow and limited to a maximum size of 4K. Furthermore, client might turn off cookies, which might cause errors on the JavaServer Page.

  • URL rewriting— You can encode the data that you need to persist across sessions in the URL. URL rewriting is similar to the use of hidden fields. The more data you need to pass over the network, the slower your application will perform.

  • Persistent mechanism— You can use a database or some other data store and persist the data to that store. This goes against various design patterns for J2EE programming and is definitely the biggest performance hit.

    [ Team LiB ] Previous Section Next Section