Data Caching in Web Applications

Tony C. Shan

Bank of America, USA Winnie W. Hua CTS Inc., USA

IntroductIon

Nowadays, the e-commerce business models demand increasingly higher performance of information systems that support various business processes. Higher levels of service at a lower cost must be provided by the informa-tion technology (IT) group to help the business compete and succeed in a global economy. IT has to find a way to extend the current infrastructure in an organization and get the most out of the existing investments by ap-plying innovative solutions. One of the most valuable innovations is scalable data management.

BAcKGround Definition

A data cache, in its simplest terms, is a data block that contains frequently accessed data in a text or binary format. The data block either may be saved to a persistent storage at the client or server side, or is persistent in memory for the lifetime of a process, a client session, or a user request. Caching is a general technique used to improve data access performance. In the case of transient data, the data retrieved from the data source is stored in a memory buffer. When an application needs to access a particular data element, the data cache is first checked to see if the data has been already stored. If there is a match, the application will use the data directly from the cache, rather than querying the data source again.

This results in a drastic performance gain, because the data access in RAM is much faster than that to a disk or external resource over the network. Moreover, the cached data is typically in a form that needs little or no transformation and initialization, which yields higher performance in the application.

Why caching

In general, a simple solution to many performance challenges is horizontal or vertical scaling. Either more servers are added or the existing machines are upgraded with additional and faster processors, extra RAM, bigger hard drives, and/or higher-speed LAN connection. In today’s competitive environment, however, the ultimate challenge is how to make our application designs perform and scale well to satisfy the capacity demand while at the same time reducing the total cost of ownership. Even though investing more on hardware alone may alleviate the pain points for a short period of time, it usually does not fix the root cause. This means that the architectural problems still remain and should be resolved by handling the data access in a more disciplined way. The best solution to systematically address this issue is usually an aggres-sive use of data caching technology.

dAtA cAcHInG tEcHnIQuES

Various types of caching technologies can be utilized as a means to improve Web application performance.

Each technique has its own specific merits and resolves a certain set of data access issues. There are a number of ways to classify the data caching techniques, de-pending on the criteria used. For example, they may be categorized into the groups of class, component, application, API, protocol, language, platform, and device. They may also be grouped as creational, struc-tural, or behavioral.

Virtually all Web applications developed today in either Java or .NET are based on an n-tier archi-tecture, which consists of a series of logical/physical tiers—client, Web, application, integration, and enter-prise information. Accordingly, a taxonomic scheme is designed in Figure 1 to sort various caching techniques

D

into appropriate tiers. In addition, some techniques are applicable in multiple tiers, which are consequently grouped in the cross-tier category.

client tier Proxy Server

A proxy server is a software or hardware device that enables applications to indirectly connect to other network resources. It is a commonly used comple-mentary technology that reduces network bandwidth consumption by sending only changed blocks of data of a dynamically constructed Web page.

HtML Form Field

Hidden fields in an HTML form are used to store ses-sion-related data. The advantages of this approach are

that this technique is independent from the server-side technology, and the data elements may be used by Web sites other than the original site that set the data. The primary downside is that the same data block has to be sent back and forth between the browser and server in each communication exchange. Binary data has to be encoded and decoded using algorithms like Base 64. Further, the name and value of the hidden input fields may have to be encrypted to protect the data elements.

HtML Hidden Frame

A hidden frame in an HTML page is used to cache data on the client browser, avoiding the roundtrips to the server that are inherent in the hidden field technique.

The data contained in a hidden frame can be accessed locally using the client-side scripting. No server re-sources are needed in this method as the data fields in Figure 1. Data caching techniques

client tier

component Disk I/O for config, log, template files like XSL stylesheets

Object caching Object type Object pooling

Collection classes

data source in Java EE container PreparedStatement Message-Driven bean (MDb) O/r mapper

Cookie Java EE patterns

(value object)

Local host file for DnS

Data Caching in Web Applications

the hidden frame are stored and read directly from the page at the client side.

UrL rewriting

URL rewriting embeds the caching data as a part of the URL request string in a session. The restriction is that a request can only be submitted to the server using HTTP GET. Moreover, although RFC 2616 (Fielding et al., 1999) does not specify any requirement for URL length, most browsers impose a cap on the URL length.

For example, the Microsoft Internet Explorer browser has a maximum URL length of 2083 characters (Mi-crosoft Support, 2006).

Client-side cookies may serve as a data cache just like the hidden fields. Data can be persistent on the client machine via a cookie. For a session cookie, the data contents will need to be set once, unlike the hidden fields that have to be set by the server-side in each response. In the scenario where multiple systems col-laborate to provide a service by transferring controls between each other, a cookie is the best choice to store the session data. However, the cookie data is sent to the server from a browser in every http request, which still creates a great deal of network traffic. Cookie data may not be accessible to other Web sites if the origina-tor sets the domain. In addition, if a user opts to turn off the cookie in the browser settings, this technique becomes useless.

RFC 2109 (Kristol et al., 1997) recommends the implementation limits of at least 4096 bytes per cookie, which is the size limit placed by most browsers today.

Support for 8192-byte size cookies is emerging in the new versions of browsers.

DnS resolver

The DNS entries may be cached to avoid DNS lookup calls. Client DNS resolvers are implemented with cache in popular Web browsers. DNS lookups are cached for 15 minutes in Mozilla, while Internet Explorer caches the DNS host entries for 30 minutes (Microsoft Sup-port, 2004).

Script variable

Cache data may be stored in variables in the JavaScript or VBscript embedded in a HTML page.

Ajax

Asynchronous JavaScript and XML (Ajax) is a Web development technique that exchanges small chunks of data with the Web server in XML format asynchronously behind the scene. This results in a more responsive interaction on the Web page as the entire Web page is not reloaded every time a user clicks a link or but-ton on the page. In the Ajax model, a great amount of data is cached at the browser side, and other blocks of data can be retrieved from the servers on demand or proactively in an asynchronous fashion.

Web tier Web Caching

Caching at the presentation layer called Web caching has been successfully leveraged to accelerate the delivery of static contents such as HTML files, images, CSS, scripts, and multimedia contents. Web caching at the Web layer can optimize the use of the view elements generated at the application tier. This type of caching significantly enhances the delivery of non-dynamic contents.

reverse Proxy Server

A reverse proxy acts as a cache for different backend servers, which enables Web pages to be delivered in a single URL space from Web servers of drastically different architectures or systems. It is noteworthy that a reverse proxy always terminates a SSL/TLS con-nection (i.e., a SSL concon-nection cannot transparently extend across a reverse proxy). As a result, it has full control over the connection including authentication header fields. Additionally, reverse proxy servers are not designed for optimized caching, so they may not scale well when network loads grow significantly, although they can be used to replicate content to geographically dispersed areas or for load balancing.

Client/Server-Side Data validation

D

Input data validation is virtually a prerequisite before the business logic is invoked. Performing data validation is a type of caching method, which avoids unnecessary hits to the backend server if the input data is invalid.

Microsoft .NET technology (Microsoft .NET, 2005) enables the IIS server to detect at run time whether to push the data validation logic to the client side. For rich client applications, the data validation logic and reusable data block are generally sent to the client side in favor of performance enhancement. This also applies to partner applications using Web services communications.

However, this translates to a tremendous amount of duplication for a large client base. Additionally, it is most likely that there is insufficient space to cache a large portion of data in pervasive computing devices like Blackberry.

ASP

Active server page (ASP) technology (Microsoft Knowledgebase, 2004) provides two objects, which enables storing key/value pairs in memory, namely session and application. The session object is used to store per-user data across multiple requests, whereas the application object is used to store per-application data for use by requests from multiple users.

ASP.nEt

The ASP.NET technology adds two types of cach-ing—output caching at the page level, and user-control level (fragment caching).

Keep-Alive in Http Header

The socket connection between a Web browser and a Web server may be preserved for subsequent hits after the first request.

HttP Header Field

Under certain circumstances, an HTTP header field may be exploited to store cache data in a session.

However, it is not recommended to use the header to contain business logic-related data, to mandate loose coupling between tiers.

no-Cache via HtML Head tag

In some scenarios like stock quotes, the output should not be cached at a browser. The HTML specification (Fielding et al., 1999) defines a way to notify the browser that it should not cache the information so that it requests the information from the server each time, and displays it.

To enforce no caching, include the following code segment between the <Head> and </Head> tags in a HTML page:

<meta HTTP-EQUIV=”Pragma” CONTENT=”no-cache”>

< m e t a H T T P - E Q U I V = ” C a c h e - C o n t ro l ” CONTENT=”no-cache”>

The first line is for HTTP Version 1.0, while the second line is for Version 1.1. This ensures that the data is not cached, so that fresh data is always retrieved from the server before serving the client’s request.

no-Cache via Http Header

The no-caching information can be alternatively trans-mitted in the Http header. The following code is for ASP applications:

<% Response.CacheControl = “no-cache” %>

<% Response.AddHeader “Pragma”, “no-cache” %>

<% Response.Expires = -1 %>

The last line prevents caching at the proxy server.

In Java EE applications, this task can also be accom-plished programmatically, by using the setHeader(), ad-dHeader(), and setDateHeader() method in the Response Class in the JSP and Servlet code, for example:

<% response.setHeader(“Cache-Control”, “no-cache”);

response.setHeader(“Pragma”, “no-cache”);

response.setDateHeader (“Expires”, 0); %>

Edge Side Includes

A Web-tier cache is also generally used to cache JSP fragments. More and more applications are moving toward JSP fragment caching. Some vendors provide custom tags for caching JSP fragments, which enables

Data Caching in Web Applications

the caching content produced within the body of the tag. The contents cached can be the final view of the content, or simply the values calculated for variables.

The latter is useful when the presentation is independent of the computed data. The JSP Tag Library for Edge Side Includes, or JESI (JSR-128 2004), is a specifica-tion of a custom tag library that uses the JSP syntax to automatically generate ESI code. ESI is a markup language that enables partial page caching for HTML fragments (ESI 2001).

Application tier HttpSession

In a Java EE application, an HttpSession object (JSR-154, 2006) can store very complex data structures with a rich set of APIs. This data cache is tied to a particular browser session. In reality, most contain-ers implement the HttpSession by means of either an in-memory replication or a separate database as persistence storage. The data can be retrieved much more rapidly from the HttpSession object than from the original data source.

One pitfall that one needs to be cautious about is that only one HttpSession object exists between a browser and a Servlet engine that persists for a period of time. If some values are placed to represent data objects in the HttpSession, this object will exist for every Servlet-based application on the server. If there are multiple Servlet applications running on the same server, they may use the same values to store data values with HttpSession. If, during the same session, the user of that session visits another Servlet applica-tion in the same container that uses the same values in HttpSession, a collision will occur.

The session time-out value, typically 60 minutes, triggers the invalidation of caching items and garbage collection. In order to save the cache space, one needs to invalidate the session and clear the cache manually, rather than relying on the container’s garbage collec-tion, which takes longer cycles than needed.

Stateful Session bean

Stateful session beans can store a relatively small chunk of data as cache in addition to the state data

for a particular user session. One of the advantages of this technique is that cross-server data replication is automatically implemented by the containers in a clustered environment. However, the stateful session beans do not scale well, and could become a bottleneck for high-volume Web applications, as the container has to manage a large number of beans with the state information.

Entity bean

Whereas a session bean is typically used to realize the business logic, an entity bean represents an instance of a persistent object. If the EJB components are deployed to a single instance of an application server, the caching of entity beans is taken full advantage of. However, the clustering and load-balancing features of the application servers are often used in most high-end applications. In the case of multiple instances deployed, it is possible that the cached entity bean is updated by another copy of this entity bean in another instance. Consequently, the ejbLoad() method should always be invoked at the beginning of a transaction to load the current state and ensure data integrity in a clustered environment.

Additionally, the entity bean is replaced by the Entity class in Java Persistence API in Java EE 5.

read-Only Entity bean

Some container vendors offer EJBs classified as read-only entity beans. This allows caching of entity beans that were marked as read-only. The configurations of caching attributes are provided via the vendor-specific deployment descriptor. Vendors also provide a propri-etary API for invalidating cached data. This solution is vendor specific and therefore not portable. Read-only entity beans are not supported in the latest EJB 3.0 specification (JSR-220, 2005).

Accessing EJb Using Local Interface

Access to EJBs in early Java EE specifications had to be implemented through a remote interface, which is implemented via RMI. The later EJB versions (EJB 2.0 above) provide the ability to access EJBs through a local interface, which should be used unless an ap-plication needs to access a remote client.

Servlet Context Singleton

D

The Servlet context implements the singleton design pat-tern. It can cache for all Servlet requests. The downside is that this resource is not managed by the container.

Singleton caches are usually designed via a Hashtable object with no limitation in size, but it leads to a similar collision issue as seen in the HttpSession object.

Attribute in Servletrequest Interface

The ServletRequest interface provides a mechanism to store an attribute in the request. The attributes are in the form of name-value pairs, where the value is a generic Java object. The setAttribute() and getAttribute() meth-ods are invoked to manage attributes in the request that is forwarded to another handler or Servlet. Be aware that the attributes are reset between requests. They are often used in conjunction with RequestDispatcher.

Web Application Frameworks

Most popular Java EE Web application frameworks such as Struts (2006), JavaServer Faces (JSR-252, 2006), and Spring (2006) all provide caching capability of the client session data at different levels: request, session, and application. If an application is developed based on one of these frameworks, these built-in features can be taken advantage of.

.nEt Framework API

Microsoft .NET framework includes a rich set of data caching APIs, which provides an in-memory, appli-cation-scoped, thread-safe space that can hold any serializable object or object collection. The .NET data caching API consists of two classes in the System.Web.

Caching namespace. The first class, Cache, is used to insert and delete data elements from the cache. The second class, CacheDependency, is used to specify a cache dependency to a data element in the cache.

The time-based expiration is built in the method Insert(). The time for invalidation can be either abso-lute or sliding. A callback function to a cached item can be implemented to be executed when that item is removed form the cache.

Web Services

In the Web services space, WS-resource framework (WSRF) and WS-addressing are emerging as the de facto mechanism for stateful Web services invocations, which caches the state data during a session.

Integration tier Cache Server

Some ecommerce systems use a dedicated integration server or middleware like message queues for applica-tion/business integration. Business integration servers are usually used for process orchestration and long-lived transactional processes. Both volatile and non-volatile data may be cached in this layer. A standalone cache server is also utilized. This is particularly useful when implementing a distributed cache. A cache server also serves as a stand-in to backend databases and legacy systems.

Connection Pool

A connection pool is a widely used practice to reuse expensively created connections such as SSL and da-tabase connections. Application servers that are Java

In document Encyclopedia of Internet Technologies (Page 151-161)