Using the Session - Beginning Hibernate: From Novice to Professional - page 190

// Run the boilerplate to close the sessions
close(s1);
close(s2);
}
}
}
Caching
Accessing a database is an expensive operation, even for a simple query. The request has to be
sent (usually over the network) to the server. The database server may have to compile the
SQL into a query plan. The query plan has to be run and is limited largely by disk perform-
ance. The resulting data has to be shuttled back (again, usually across the network) to the
client, and only then can the application program begin to process the results.
Most good databases will cache the results of a query if it is run multiple times, eliminat-
ing the disk I/O and query compilation time; but this will be of limited value if there are large
numbers of clients making substantially different requests. Even if the cache generally holds
the results, the time taken to transmit the information across the network is often the larger
part of the delay.
Some applications will be able to take advantage of in-process databases, but this is the
exception rather than the rule—and such databases have their own limitations.
The natural and obvious answer is to have a cache at the client end of the database con-
nection. This is not a feature provided or supported by JDBC directly, but Hibernate provides
one cache (the first-level, or L1, cache) through which all requests must pass. A second-level
cache is optional and configurable.
The L1 cache ensures that within a session, requests for a given object from a database
will always return the same object instance, thus preventing data from conflicting and pre-
venting Hibernate from trying to load an object multiple times.
Items in the L1 cache can be individually discarded by invoking the evict() method on
the session for the object that you wish to discard. To discard all items in the L1 cache, invoke
the clear() method.
In this way, Hibernate has a major advantage over the traditional JDBC approach: with no
additional effort from the developer, a Hibernate application gains the benefits of a client-side
database cache.
Figure 8-3 shows the two caches available to the session: the compulsory L1 cache,
through which all requests must pass, and the optional level-two (L2) cache. The L1 cache will
always be consulted before any attempt is made to locate an object in the L2 cache. You will
notice that the L2 cache is external to Hibernate; and although it is accessed via the session in
a way that is transparent to Hibernate users, it is a pluggable interface to any one of a variety
of caches that are maintained on the same JVM as your Hibernate application or on an exter-
nal JVM. This allows a cache to be shared between applications on the same machine, or even
between multiple applications on multiple machines.
In principle, any third-party cache can be used with Hibernate. An org.hibernate.cache.
CacheProvider interface is provided, which must be implemented to provide Hibernate with a
handle to the cache implementation. The cache provider is then specified by giving the imple-
mentation class name as the value of the hibernate.cache.provider_class property.