One of the common issues application architects must face is how to cache database information reliably to increase overall system performance. Temporary Java Cache (a.k.a. JCACHE) is an upcoming standard specification (JSR 107) that addresses this problem. It specifies an approach for temporary, middle-tier in-memory caching of Java objects, including object creation, shared access, spooling, invalidation, and consistency across JVMs. It can be used to cache read-mostly data such as product catalogs, price-lists and so on, within JSP pages.

In order to track all the changes to the origin data and refresh the cached data, a Java stored procedure is attached to a table, as a trigger. Any change to this table will result in the automatic invocation of this stored procedure, which in his turn will call-out a defined JSP (using OracleJVM HTTP call-out) to invalidate the JCACHE object that maps its state to the database table. Upon invalidation, the very next query will force the cache to be refreshed from the database.

Stored procedures allow a clean separation of data logic and persistence logic that runs in the database tier from business logic and presentation logic that run in the middle tier. This separation reduces overall application complexity and increases reuse, security, performance and scalability. Java-based stored procedures are a standard (ANSI SQL-1999 SQLJ-Part-1 a.k.a. "SQL routines using Java") database-independent alternative to proprietary procedural extensions to SQL, such as Oracle's PL/SQL. Oracle9i database embeds an integrated Java VM which enables Java stored procedures, functions and triggers, but also, as we will illustrate in upcoming article, bridging the worlds of SQL, XML, Java, J2EE, and Web Services.

In this demo, we have implemented a Product Information system, in which the product catalog is mostly read-only. The corresponding products table in the database may be updated either through the same Java Server Pages application (running on Oracle9iAS OC4J) or SQL prompt. Using JCACHE, most queries will have response times an order of magnitude faster because of cached data (in-house testing showed fifteen times faster response time).

For a complete information on the architecture, downloading and configuring the demo, refer to the Readme.