Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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. In this article, Srini Penchikala discusses a simple caching implementation framework he created to cache the lookup data objects in a Web portal project.
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.
Now that we have covered the basics of how caching works, let's look at some of the well-known scenarios in a J2EE application that use object storage mechanisms similar to caching.
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.
A portal must manage both user profiles and the objects available at the portal. Since most Web portals provide the single sign-on (SSO) feature, storing the user profile data is critical even if the user switches between various modules in the Web portal application. The user profiles should be securely stored in the cache so other Web users cannot access them. The objects can be aged out of the cache to free up space or the idle-time feature can remove objects not being accessed. This simplifies object management, as the application doesn't need to constantly monitor which objects are in demand at any given time. The "hot" objects are automatically available in the cache. Objects that are expensive to create or fetch can be written to a local disk and transparently retrieved as needed. Thus, object caching may be used for managing the user profile information and lookup data, such as company product information, that can be shared among multiple portal users.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Considerations for clusterable software... By sent2null|
|J2EE object-caching frameworks By JavaWorld|
|JCS doese it Support Clustering or not clarify By Anonymous|
|JOCache's cluster support By Anonymous|
|What about JSP --> HTML cache? By Tomer|