First-Level and Second-Level Caches

Hibernate implements a simple session-level cache, useful on a per-transaction basis. This cache is primarily used to optimize the SQL generated by Hibernate. It is sometimes referred to as a first-level Hibernate cache.
The JVM and distributed cache discussed in this section is referred to as a second-level cache in other sources. Since you will never need to configure the first-level cache, the discussion in the rest of this section will refer to the second-level cache simply as "the cache."
Let's start by looking at Hibernate without a cache, as shown in the following figure. Data is transferred between Hibernate and the database, and transactions are managed by the database. Hibernate assumes that the data in memory should be refreshed on every access (a reasonable assumption, especially if Hibernate does not have exclusive access to the database).

Hibernate without a Cache

The following figure shows Hibernate operating with a single JVM cache used to minimize traffic between Hibernate and the database. This will increase the performance of the application and minimize the load on the database, but at the cost of a bit more configuration complexity (described later in this section) and memory usage. If you are interested in sharing object data across threads, simply use a cache, as shown in the following figure.

Hibernate with a Cache

The following figure illustrates a problem that may arise when you use a cache. If your application does not have exclusive access to the database (a common situation in an enterprise environment), your cache can easily become out of sync with the database. If a legacy application updates a record stored in the cache, by default there is no notification to the cache that the data is stale, and therefore the data in the cache will be incorrect.

Hibernate and a Legacy System

Multiple SessionFactory Objects

A JVM cache, as described here, is actually a SessionFactory-level cache. There is normally no reason not to share a SessionFactory instance throughout your JVM instance; but if for some reason your application uses more than one SessionFactory, you're effectively building a multiple JVM system, and therefore you will need to use a distributed/clustered cache.
Similarly, if you have multiple JVMs running on a single physical system, that still counts as a distributed system.
Unfortunately, there is no ideal solution to the problem of distributed object cache in conjunction with a legacy system. If your Hibernate application has a read-only view of the database, you may be able to configure the GigaSpaces cache to expire data.

If you need to have a synchronized cache with SQL access to be used by your application and your legacy systems, you may consider using GigaSpaces JDBC for the legacy systems and your application to share the same data while having high-performance and high-availability.

If you are able to control all the access to a particular database instance, you may be able to use the GigaSpaces distributed cache to ensure that the data traffic is properly synchronized. An example of this is shown in the following figure. Since the overhead accessing GigaSpaces cache is minimal, there would not be any performance impact when adding the cache layer.

Hibernate and a Distributed Cache