Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Tool Report: livestore

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

Published November 2002

The Tool Reports are designed to help readers make informed choices about the tools they may wish to use. provides these reports as a service to our readers; is not responsible for the information provided by the tool author or vendor, nor do we necessarily endorse the products mentioned. is not responsible for any additional resources provided from the article (such as downloadable files or other accessible material), even where we host such material.


The move away from client-server and towards multi-tier architectures has tended to separate business logic from its data. Keeping data close to where it is accessed, by means of caching, is a well known solution to performance and scalability problems but the use of highly productive generic component frameworks, such as J2EE, has reduced the ability of developers to cache data without competing with the spirit of these component technologies.

livestore takes a unique approach to caching that enables J2EE component developers to write J2EE compliant components, such as Entity Beans (CMP or BMP), Session Beans, Servlets or Java Server Pages completely independently from livestore. livestore let's you keep your components pure in that they only use standard J2EE APIs. This allows them to be reused in non- livestore situations thus avoiding the vendor lock-in that has become so common with other products. Once components are functionally complete and portable, livestore can then be configured into the system to improve their performance and scalability.

In order to provide this completely seamless caching facility to all forms of components that may wish to access enterprise data, livestore exposes itself using the only data access API that is part of the J2EE specification: Java DataBase Connectivity - JDBC.

Enterprise scale applications often require multiple servers to be clustered together. livestore provides a synchronisation facility that enables clusters of livestore enabled applications to keep a consistent and up-to-date cache of dynamic business data.

Using livestore in an Application

Adding livestore caching to an application is a simple four-step process, which will normally require no changes to your application code. In this article, we will walk through a simple example. The application is a simple, standalone payroll application that has two tables, named EMPLOYEE and DEPARTMENT. The EMPLOYEE table has columns ID, FORENAME, SURNAME, DEPARTMENT and SALARY. The DEPARTMENT table has columns ID and NAME.

To use livestore with this simple database, we need to go through the following step.

  1. Add an optimistic control column

    livestore requires an additional, integer column on each table that you want to be cached. This column is used by livestore for optimistic concurrency control. It is managed automatically by livestore and your application need never know about it. In this case, we add a column named VERSION to each table.

    livestore also requires that each table has a primary key constraint, but you will usually already have these in place. In this example, the primary key in both tables is the column named ID.

  2. Add livestore.jar to your classpath

    If you are using an application server, you will need to do this by modifying your server startup scripts, or changing its configuration as described in its documentation. If your application is stand-alone, you can do it my modifying the CLASSPATH environment variable, or the command line used to start your application. In the example, the application is standalone, so we modify the CLASSPATH environment variable to include livestore.jar.

  3. Generate a livestore configuration file

    The easiest way to do this is to use the configuration generator supplied with livestore. You can find it in the bin directory of the installation, and run it like this:

    config-gen.bat c:\payroll\livestore-config.xml -username payroll -password payroll
                                                   -driverClass oracle.jdbc.driver.OracleDriver
                                                   -diverUrl jdbc:oracle:thin:@payroll:1521:payroll
                                                   -ocCol VERSION
                                                   -schemaPattern PAYROLL
                                                   -maximumCapacity 10

    The configuration generator reads the database metadata, checks that it is suitable for use with livestore, and generates a configuration file to the supplied filename. The first four arguments should be self-explanatory, as they are common to many JDBC-based applications. The -ocCol argument is just the name of the optimistic control column we added to the schema in step one. The -schemaPattern argument lets you define the part of the database to output configuration for (there is also a -catalog argument). The -maximumCapacity argument lets you set the maximum number of database connections the application will use. Initially, you should set this to the size of the connection pool you have been using without livestore, but using livestore will enable you to reduce it later.

  4. Reconfigure the application to use livestore

    Most J2EE applications read their configuration information either from an external file, or fetch it from an application server. This configuration information tells them which JDBC driver to use. In the case of our payroll application, we simply modify the file to replace mentions of the JDBC driver class name with com.isocra.livestore.api.factories.Driver, and the database URL with jdbc:livestore:file:\c:\payroll\livestore-config.xml.

Once these steps have been performed, the next time the application is run, all database queries will be routed via livestore instead of via the original JDBC driver.

What livestore is doing

The very small amount of configuration we have done is already enough to give the payroll application a significant performance boost. With the configuration we have generated automatically, livestore will already be able to cache the responses to any query using the primary key of any cached table. This accounts for a great many of the queries performed by typical J2EE applications.

In our payroll example, there is a facility to display all the information about a particular employee. This is done using a query like this:


The first time livestore sees this query, it will send it to the database, and cache the result. If the application performs the same query again, however, the answer will come from livestore's cache. A query response retrieved from cache reaches your application orders of magnitude faster than if it had been retrieved from the database.

livestore can also keep its cache up-to-date with changes made by the application. If, after the query above, the application were to modify the employee's salary with an update like this:


livestore will not evict the row representing employee number 235 from the cache, but instead, it will update it to reflect the change as well as writing the update through to the database itself.


Even though livestore can produce substantial performance improvements on primary key queries alone, it is possible to make use of its cache for other queries too. For example, you may well want to find all the employees in a department with a query like this:


With the automatically generated configuration, it will not be possible to answer this query from cache unless the cache already contains all the employees, which is unlikely to happen very often.

However, by adding a single line to the configuration file, you can add an index to the livestore cache as follows:

<Index columns="DEPARTMENT" cache="true" unique="false"/>

With this entity added to the configuration file, livestore will cache the results of queries using the DEPARTMENT column, so if the query above was performed twice, the second time the result would come from the cache.

Find Out More

You can download an evaluation copy of livestore from, or you can find out more about livestore at

About Isocra

Isocra was founded in 1998 in a response to the need for a greater emphasis on design excellence and sound engineering principles in leading-edge technologies. Isocra specialises in technologies such as e-commerce, distributed objects and enterprise software. The company is based in Cambridge, UK. To find out more about isocra see the website at

Last Updated: 2023-08-28
Copyright © 2000-2023 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us