J2EE object-caching frameworks

Improve performance in Web portal applications by caching objects

Web applications are typically accessed by many concurrent users. Usually, the application's data is stored in a relational database or filesystem, and it takes time and costs overhead to access these data sources. Database-access bottlenecks can slow down or even crash the application if it receives too many simultaneous requests. Object caching is one technique that overcomes this problem.

Object caching allows applications to share objects across requests and users, and coordinates the objects' life cycles across processes. By storing frequently accessed or expensive-to-create objects in memory, object caching eliminates the need to repeatedly create and load data. It avoids the expensive reacquisition of objects by not releasing the objects immediately after their use. Instead, the objects are stored in memory and reused for any subsequent client requests.

Here's how caching works: When the data is retrieved from the data source for the first time, it is temporarily stored in a memory buffer called a cache. When the same data must be accessed again, the object is fetched from the cache instead of the data source. The cached data is released from memory when it's no longer needed. To control when a specific object can be released from memory, a reasonable expiration time must be defined, after which, data stored in the object becomes invalid from a Web application's standpoint.

Conventional methods for object lookup such as a simple hashtable, JNDI (Java Naming and Directory Interface), or even EJB (Enterprise JavaBeans) provide a way to store an object in memory and perform the object lookup based on a key. But none of these methods provide any mechanism for either removing the object from memory when it's no longer needed or automatically creating the object when it's accessed after expiration. The HttpSession object (in the servlet package) also allows objects to be cached, but lacks the concepts of sharing, invalidation, per-object expiration, automatic loading, or spooling, which are the essential elements of a caching framework.

Middleware technologies such as EJB and CORBA allow the remote transfer of objects where the remote object is transferred between the client and the server. This type of access, also known as coarse-grained data access, minimizes the number of expensive remote method invocations. These data-transfer objects (also known as value objects) can be stored in the cache if the objects don't change frequently, which limits the number of times the servlet container must access the application server.

More examples of object-caching uses follow:

Enterprise JavaBeans: EJB entity beans represent database information in the middle tier, the application server. Once created, the entity beans are cached in the EJB container, which avoids expensive data retrieval (resource acquisition) from the database.
EJBHomeFactorycache: If client applications don't cache the stub somewhere, then remote method invocation can become much more expensive because every logical call to the server requires two remote calls: one to the naming service to fetch a stub and one to the actual server. This problem can be solved by creating an EJBHomeFactory class to cache the references to EJB Home interfaces and reusing them for the subsequent calls.
Web browsers: Most popular Web browsers such as Netscape and Internet Explorer cache frequently accessed Webpages. If a user accesses the same page, the browsers fetch the page's contents from the cache, thus avoiding the expensive retrieval of the contents from the Website. Timestamps determine how long to maintain the pages in the cache and when to evict them.
Data cache: Data stored in a RDBMS (relational database management system) is viewed as a resource that is sometimes hard to acquire. A correctly sized cache is a crucial component of a well-tuned database. Most databases incorporate a data cache of some sort. Oracle, for example, includes a shared global area that contains a cache of recently used database blocks and caches of compiled stored procedure code, parsed SQL statements, data dictionary information, and more.

How about data not fit for caching? Here's a list of data not recommended for caching:

Secure information that other users can access on a Website
Personal information, such as Social Security Number and credit card details
Business information that changes frequently and causes problems if not up-to-date and accurate
Session-specific data that may not be intended for access by other users

changing application architecture diagram.jpg