Caching in the application server tier is widely accepted as a best practice for reducing database bottlenecks. By satisfying a large portion of client requests from cached data, an application saves an extra network bounce (to the database) and relieves the load on the database, allowing it to more efficiently handle the critical operations that modify the data set. Progress® DataXtend™ CE can help.
While relational databases can be highly optimized and efficient, they simply were not designed to handle the high volumes of traffic generated in many enterprise systems. The limited number of connections places a threshold on the number of requests that can be handled concurrently. When all connections are in use, incoming requests are blocked. The locks required during updates can cause additional delays.
This subject covers the following topics:
With data caching you have two choices, build or buy. Building a caching system has disadvantages similar to writing your own data access: it siphons resources away from the development of your business-specific logic and it requires starting from scratch—incurring design, development, and testing overhead.
There are several different approaches to caching objects in an application. Some caches present data in structures that mirror the database's rows, columns, and tables, thus exposing the details of the database schema to the application code. Other caches treat objects as opaque data, which makes it impossible for the cache to understand and manage relationships between objects. These straightforward approaches generally work best for applications dealing with simple data that does not change frequently.
Both home-grown and most purchased data caching services are usually designed to handle read-only or predictably changing data. When data changes predictably, an application can easily refresh the cache periodically to ensure that all clients have accurate information. But when information changes unpredictably, the burden falls on the developer to synchronize data. This is a difficult problem that is just too complex to address on an application-by-application basis. The difficulty of synchronizing data increases exponentially as application servers are clustered to support more clients or higher availability.
Take DataXtend CE for a 30-day test drive.
Rather than restricting caching to read-only data or maintaining separate views of volatile data, DataXtend CE provides a multi-threaded shared cache for each server process. As users update data, DataXtend CE creates an isolated transactional cache for each. The changes are invisible to other users until the transaction commits. Upon commit, DataXtend CE updates the shared cache with the freshest information.
DataXtend CE's intelligent data caching offers a unique combination of features to support applications with complex object models and/or high request rates:
While most applications perform well with the intelligent cache's default settings, every application has its own data access patterns. DataXtend CE advanced cache management service and database tuning features (such as cache indexing, lazy loading, and database write policies) are configurable and do not require code changes or recompilation.
Because of its tight integration with the data model, DataXtend CE caching is nearly transparent. An application can control which objects stay in the cache and which are cleared when not in use. Requests for application data can specify whether the data should be retrieved from the cache or the database. The following illustration shows how caching works when DataXtend CE is integrated with a J2EE application server.

Figure 1: Java Virtual Machine
An object does not exist in either cache (shared or transactional) until DataXtend CE receives a request for that object. The first invocation on a mapping object causes DataXtend CE to do the following:
Requests in a transactional context populate a transactional cache, one cache per transaction scope. Reads outside of a transaction populate the shared cache. DataXtend CE performs the following when a transaction commits (these actions are atomic; all occur or none):
DataXtend CE uses the primary key of each object to identify it. This prevents the server from duplicating objects in the cache and supports find-by-key functionality.
> OR Mapping
> Cache Clustering
> DataXtend CE
> Download DataXtend CE
> Data Integration Resource Center
> Partner Programs
Contact us to gain more insight and to learn more about the products and technologies from Progress Software.