Sessions

From the examples in the earlier chapters, you will have noticed that a small number of classes dominate our interactions with Hibernate. Of these, Session is the linchpin.

The Session object is used to create new database entities, read in objects from the database, update objects in the database, and delete objects from the database.¹ It allows you to manage the transaction boundaries of database access, and (in a pinch) to obtain a traditional JDBC connection object so that you can do things to the database that the Hibernate developers have not already considered in their existing design.

If you are familiar with the JDBC approach , it helps to think of a Session object as somewhat like a JDBC connection, and the SessionFactory, which provides Session objects, as somewhat like a ConnectionPool, which provides Connection objects. These similarities in roles are illustrated in Figure 8-1.

Figure 8-1. Similarities between Hibernate and JDBC objects

SessionFactoryobjects are expensive objects; needlessly duplicating them will cause problems quickly, and creating them is a relatively time-consuming process. Ideally, you should have a single SessionFactory for each database your application will access.

SessionFactory objects are threadsafe, so it is not necessary to obtain one for each thread. However, you will create numerous Session objects — at least one for each thread using Hibernate. Sessions in Hibernate are not threadsafe, so sharing Session objects between threads could cause data loss or deadlock. In fact, you will often want to create multiple Session instances even during the lifetime of a specific thread (see the “Threads” section for concurrency issues).

We’ve already covered the core methods in Chapter 4, so we won’t discuss all the methods available to you through the Session interface. For an exhaustive look at what’s available, you should read the API documentation on the Hibernate website or in the Hibernate 5 download. Table 8-1 gives a broad overview of the various categories of methods available to you; despite its length, this is not an exhaustive list.

Transactions and Locking

Transactions and locking are intimately related: the locking techniques chosen to enforce a transaction can determine both the performance and the likelihood of success of the transaction. The type of transaction selected dictates, to some extent, the type of locking that it must use.

You are not obliged to use transactions if they do not suit your needs, but there is rarely a good reason to avoid them. If you decide to avoid them, you will need to invoke the flush() method on the session at appropriate points to ensure that your changes are persisted to the database.

Session session = factory.openSession();
try(Session session = factory.openSession()) {
  session.beginTransaction();

  // Normal session usage here¼

  session.getTransaction().commit();
} catch (HibernateException e) {
  Transaction tx = session.getTransaction();
  if (tx.isActive()) tx.rollback();
}

@Test
public void showDeadlock() throws InterruptedException{
    Long publisherAId;
    Long publisherBId;

    // clear out the old data and populate tables
    try (Session session = SessionUtil.getSession()) {
        Transaction tx = session.beginTransaction();
        session.createQuery("delete from Publisher").executeUpdate();

        Publisher publisher = new Publisher();
        publisher.setName("A");
        session.save(publisher);
        publisherAId=publisher.getId();

        publisher = new Publisher();
        publisher.setName("B");
        session.save(publisher);
        publisherBId=publisher.getId();
        tx.commit();
    }

    ExecutorService executor = Executors.newFixedThreadPool(2);
    executor.submit(() -> updatePublishers("session1", publisherAId, publisherBId));
    executor.submit(() -> updatePublishers("session2", publisherBId, publisherAId));
    executor.shutdown();

    if (!executor.awaitTermination(60, TimeUnit.SECONDS)) {
        executor.shutdownNow();
        if (!executor.awaitTermination(60, TimeUnit.SECONDS)) {
            System.out.println("Executor did not terminate");
        }
    }
    try (Session session = SessionUtil.getSession()) {
        Query<Publisher> query = session.createQuery("from Publisher p order by p.name",
            Publisher.class);
        String result=query
            .list()
            .stream()
            .map(Publisher::getName)
            .collect(Collectors.joining(","));
        assertEquals(result, "A,B");
    }
}

private void updatePublishers(String prefix, Long¼ ids){
    try (Session session = SessionUtil.getSession()) {
        Transaction tx = session.beginTransaction();
        for(Long id:ids) {
            Thread.sleep(100);
            Publisher publisher = session
                    .byId(Publisher.class)
                    .load(id);
            publisher.setName(prefix+" "+publisher.getName());
        }
        tx.commit();
    } catch (InterruptedException | PessimisticLockException e) {
        e.printStackTrace();
    }
}

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 performance. 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, eliminating 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 connection. 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 (L2) 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 preventing 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-2 shows the two caches available to the session: the compulsory L1 cache, through which all requests must pass; and the optional 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 external JVM. This allows a cache to be shared between applications on the same machine, or even among multiple applications on multiple machines.

Figure 8-2. The session’s relationship to the caches

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 implementation class name as the value of the hibernate.cache.provider_class property .

In practice, the four production-ready caches, which are already supported, will be adequate for most users (see Table 8-4).

The type of access to the L2 cache can be configured on a per-session basis by selecting a CacheMode option (see Table 8-5) and applying it with the setCacheMode() method .

The CacheMode setting does not affect the way in which the L1 cache is accessed.

The decision to use an L2 cache is not clear-cut. Although it has the potential to greatly reduce access to the database, the benefits depend on the type of cache and the way in which it will be accessed.

A distributed cache will cause additional network traffic. Some types of database access may result in the contents of the cache being flushed before they are used; in this case, it will be adding unnecessary overhead to the transactions.

The L2 cache cannot account for the changes in the underlying data, which are the result of actions by an external program that is not cache aware. This could potentially lead to problems with stale data, which is not an issue with the L1 cache.

In practice, as with most optimization problems, it is best to carry out performance testing under realistic load conditions. This will let you determine if a cache is necessary and help you select which one will offer the greatest improvement.

Actually, configuring for cache usage is fairly simple. In order to set everything up, in this example, we will need to do the following:

1. Select a cache provider and add the dependency to Maven.

2. Configure Hibernate to use the cache provider for a second-level cache.

3. Alter our entities to mark them as cacheable.

We’ll choose EhCache as a cache provider, as it’s trivial to set up in a Java SE environment. The dependency block for Maven will look like this:

<dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-ehcache</artifactId>
        <version>4.2.8.Final</version>
</dependency>

Now, we need to add three properties to Hibernate that will tell it to use a second-level cache and which cache to use:

<property name="cache.use_second_level_cache">true</property>
<property name="hibernate.cache.use_query_cache">true</property>
<property name="hibernate.cache.region.factory_class">
        org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory
</property>

The last thing we need to do is mark the entity as cacheable. In Listing 8-4, we’ll create a simple Supplier entity (which we’ll revisit in the next chapters) and show how it’s used:

Listing 8-4. A Simple, Cacheable Supplier Entity

package chapter08.model;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

import javax.persistence.*;
import java.io.Serializable;

@Entity
@Cacheable
@Cache(usage = CacheConcurrencyStrategy.READ_ONLY)
public class Supplier implements Serializable {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    Integer id;
    @Column(unique = true)
    String name;
}

We’re not showing the mutators, accessors, equals(), or hashCode() methods, of course.

Now, if we load a specific Supplier in one session, then immediately load the same Supplier in another session, the database will not (necessarily) be queried because it’s being pulled from the second-level cache instead of from the database each time. Using different sessions is necessary because the Supplier instance would be cached in the first-level cache of each Session; the sessions share a second-level cache and not a first-level cache.

Threads

Having considered the caches available to a Hibernate application, you may now be concerned about the risk of a conventional Java deadlock if two threads of execution were to contend for the same object in the Hibernate session cache.

In principle, this is possible, and unlike database deadlocks, Java thread deadlocks do not time out with an error message. Fortunately, there is a very simple solution:

Patient: Doctor, it hurts when I do this.

Doctor: Don’t do that, then. ³

Do not share the Session object between threads. This will eliminate any risk of deadlocking on objects contained within the session cache.

The easiest way to ensure that you do not use the same Session object outside the current thread is to use an instance local to the current method. If you absolutely must maintain an instance for a longer duration, maintain the instance within a ThreadLocal object. For most purposes, however, the lightweight nature of the Session object makes it practical to construct, use, and destroy an instance, rather than to store a session.

Summary

In this chapter, we have discussed the nature of Session objects and how they can be used to obtain and manage transactions. We have looked at the two levels of caching that are available to applications, and how concurrent threads should manage sessions.

In the next chapter, we discuss the various ways in which you can retrieve objects from the database. We also show you how to perform more complicated queries against the database using HQL.