If you're working on a standalone Java application, how do you achieve transaction demarcation?

In a multiuser application, you need more than one connection to support multiple concurrent users. It's also expensive to create new connections when you need to interact with the database. For this, you need to have a connection pool that creates and manages database connections. Every thread that needs to interact with the database requests a connection from the pool and executes its queries. After it's done, the connection is returned to the pool. Then, if another thread requests a connection, the connection pool may provide it with same connection.

Usually, an application server provides a connection pool. When you're working in a standalone Java application, you need to use a third-party solution that provides connection pools. Hibernate comes with an open source third-party connection pooling framework called C3P0. Apache also provides a connection-pooling framework called Commons DBCP. You need to configure Hibernate to use one of these frameworks. After the connection pool is configured, you can use the Hibernate's Transaction API for transaction demarcation and use connections from the connection pool.

You need to add the Java c3p0-0.9.1.jar file that comes with Hibernate to the build path. In your Eclipse IDE, select your Java project, and right-click to edit build path. (See the explanation in Chapter 1 if you have trouble adding the jar to the build path.) In the Hibernate.cfg.xml file, add the following configuration:

<property name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider
</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.max_size">10</property>
<property name="hibernate.c3p0.timeout">300</property>
<property name="hibernate.c3p0.max_statements">50</property>
<property name="hibernate.c3p0.acquire_increment">1</property>
<property name="hibernate.c3p0.idle_test_period">3000</property>

Here's an explanation for each of the parameters you set:

These are all the settings required in the configuration file. Hibernate also provides a property called hibernate.transaction.factory_class that you can set in the configuration file. It provides the factory to use to instantiate transactions, and it defaults to JDBCTransactionFactory:

SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();
Session session = sessionFactory.openSession();
Transaction tx = null;
try {
        tx = session.beginTransaction();
        BookCh2 book = new BookCh2();
        book.setName("Hibernate Recipes Book  ");
        book.setPrice(200);
        book.setPublishDate(new Date());
        session.saveOrUpdate(book);
        tx.commit();

        } catch (RuntimeExceptione) {
                try{
                        if(tx != null)
                        {
                                tx.rollback();
                        }
                }catch(RuntimeException ex)
                {
                        log.error("Cannot rollback transaction");
                }
                throw e;
        } finally {
                session.close();
        }

The session is provided by the sessionFactory.openSession() call. A database connection isn't opened when the session is created; this keeps the session creation a non-expensive task. The database connection is retrieved from the connection pool when the call session.beginTransaction() is made, and all queries are executed using this connection. The entities to be persisted are cached in the persistent context of the session. The commit() on the Transaction flushes the persistent context and completes the save of the entities. Another Transaction can be opened after the current Transaction is committed. Then, a new connection is provided by the connection pool. All resources and connections are release when close() is called on the Session.

The exceptions thrown by Hibernate are RuntimeExceptions and subtypes of RuntimeExceptions. These exceptions are fatal, and hence you have to roll back your transactions. Because rolling back a transaction can also throw an exception, you have to call the rollback method within a try/catch block.

In JPA, you have to define the same configurations as for Hibernate, and the EntityTransaction API is used to manage transactions:

EntityManager manager = null;
EntityTransaction tx = null;
try {
        EntityManagerFactory managerFactory =
Persistence.createEntityManagerFactory("book");
        manager = managerFactory.createEntityManager();
         tx = manager.getTransaction();
        tx.begin();
        BookCh2 newBook = new BookCh2();

newBook.setBookName("Hibernate Recipes Phase1");
        newBook.setPublishDate(new Date());
        newBook.setPrice(new Long(50));
        manager.persist(newBook);
        tx.commit();
        log.debug("Transaction committed");
}catch (RuntimeException e)
{
        try
        {
                if(tx != null)
                {
                        tx.rollback();
                }
        }catch(RuntimeException ex)
        {
                log.error("Cannot rollback transaction");
        }

        throw e;
} finally
{
        manager.close();
}

getTransaction() is called on the EntityManager to get a transaction. The actual connection is requested from the pool with the transaction's begin() method. The commit() on the transaction flushes the persistent context and completes the save of the entities. The EntityManager's close() method is called in the finally block to make sure the session is closed even in the case of an exception.

Suppose you're using an application server that provides support to manage resources. Application servers like WebLogic, WebSphere, and JBoss can provide connections from a connection pool and manage transactions. How do you achieve programmatic transaction demarcation using the Java Transaction API (JTA)?

You have to configure a Java enterprise application with Hibernate as the persistent framework. You also need to configure Hibernate to use JTATransactionFactory to provide JTATransaction objects. You then need to use the UserTransaction interface to manage transactions programmatically.

You use WebLogic (version 9.2) as the application server to demonstrate using JTA for programmatic transaction demarcation. The assumption is that you're well versed with building and deploying your application.

To begin, you need to configure the data source on the application server. To do so, you need to start the WebLogic server, log in to the console, and configure the data source. You must also add the database driver to the server library. For Derby, you add derbyClient.jar to the server library. Make sure you test connectivity from the console!

You need to the provide the following information (with your values):

After you successfully configure the data source on the application server, you need to configure Hibernate. The key properties you're required to provide are as follows:

The following is the Hibernate configuration:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
                "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
                "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
    <session-factory name="book">
            <property name="hibernate.connection.datasource">local_derby</property>
        <property
name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>

<property
name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WeblogicTransactionManagerLookup</property>
         <property name="hibernate.dialect">org.hibernate.dialect.DerbyDialect</property>
        <property name="hibernate.show_sql">true</property>
        <property name="hibernate.cache.use_second_level_cache">false</property>
       <mapping resource="book.xml" />

    </session-factory>
 </hibernate-configuration>

You now need to write a class that provides SessionFactory for the complete application. To do so, you defined a utility class that has a static method to return the SessionFactory. Here's the code implementation:

import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;

public class HibernateUtil {

        private HibernateUtil(){}

        public static SessionFactory getSessionFactory()
        {
                SessionFactory factory = null;;
                try {

                        factory = new Configuration().configure().buildSessionFactory();

                } catch (Exception e) {

                        e.printStackTrace();
                }
                return factory;
        }
}

Now you're ready to use JTA for transaction demarcation. You get the UserTransaction by looking up the JNDI registry:

public void saveBook(Book book) throws NotSupportedException, SystemException, NamingException, Exception {
                System.out.println("Enter DAO Impl");
                Session session = null;
                UserTransaction tx = (UserTransaction)new InitialContext()
                .lookup("java:comp/UserTransaction");
                try {

                        SessionFactory factory = HibernateUtil.getSessionFactory();
                        tx.begin();
                        session = factory.openSession();

session.saveOrUpdate(book);
                        session.flush();
                        tx.commit();

                }catch (RuntimeException e) {

                        try
                        {
                                tx.rollback();
                        }catch(RuntimeException ex)
                        {
                                System.out.println("**** RuntimeException in BookDaoImpl ");
                        }
                        throw e;

                }finally
                {
                        session.close();
                }
        }

Note that you explicitly call session.flush(). You need to do an explicit flush because Hibernate's default implementation doesn't flush the session. You can, however, override the default implementation by configuring the hibernate.transaction.flush_before_completion property. You also configure the hibernate.transaction.auto_close_session property to avoid calling session.close() explicitly in every method. The Hibernate configuration file is as follows:

<session-factory name="book">
            <property name="hibernate.connection.datasource">local_derby</property>
        <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
        <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WeblogicTransactionManagerLookup</property>
        <property name="hibernate.transaction.flush_before_completion">true</property>
        <property name="hibernate.transaction.auto_close_session">true</property>
        <property name="hibernate.dialect">org.hibernate.dialect.DerbyDialect</property>
        <property name="hibernate.show_sql">true</property>
        <property name="hibernate.cache.use_second_level_cache">false</property>

        <!--<property name="hbm2ddl.auto">create</property>-->

            <mapping resource="book.xml" />

    </session-factory>

And the code looks a little simpler, as shown here:

Session session = null;
                UserTransaction tx = (UserTransaction)new InitialContext()

.lookup("java:comp/UserTransaction");
                try {

                        SessionFactory factory = HibernateUtil.getSessionFactory();
                        tx.begin();
                        session = factory.openSession();
                        session.saveOrUpdate(book);
                        tx.commit();

                }catch (RuntimeException e) {

                        try
                        {
                                tx.rollback();
                        }catch(RuntimeException ex)
                        {
                                System.out.println("**** RuntimeException in BookDaoImpl ");
                        }
                        throw e;

                }

In JPA, the implementation is very similar to Hibernate:

EntityManager manager = null;
UserTransaction tx = (UserTransaction)new InitialContext()
                .lookup("java:comp/UserTransaction");

try {
        EntityManagerFactory managerFactory = HibernateUtil.getFactory();
             manager = managerFactory.createEntityManager();
         tx.begin();
        manager.persist(book);
        tx.commit();
        }catch (RuntimeException e)
        {
                try
                {
                        if(tx != null)
                        {
                                tx.rollback();
                        }
                }catch(RuntimeException ex)
                {
                        System.out.println ("Cannot rollback transaction");
                }

                throw e;
        } finally {
                manager.close();
        }

Suppose two transactions are trying to update a record in the database. The first transaction updates and commits successfully. The second transaction tries to update and fails. So, the transaction is rolled back. The problem is that the first update is lost. Or, what if the second transaction successfully updates, as illustrated in Table 13-1? The changes made by the first transaction are overwritten.

How do you handle such cases of lost updates? And how do you enable versioning in Hibernate?

You need to understand isolation levels in order to choose a concurrency control mechanism. Access to database records is classified as reads and writes. The concurrency control mechanisms define the rules that dictate when to allow reads and writes.

A dirty read occurs when one transaction reads changes made by another transaction that haven't yet been committed (see Table 13-2). Basically, a dirty read means reading uncommitted data.

An unrepeatable read occurs when a transaction reads a record twice and the record state is different between the first and the second read. This happens when another transaction updates the state of the record between the two reads (see Table 13-3).

A phantom read occurs when a transaction executes two identical queries, and the collection of rows returned by the second query is different from the first. This also happens when another transaction inserts records into or deletes records from the table between the two reads.

Isolation defines how and when changes made by one transaction are made visible to other transactions. Isolation is one of the ACID properties. For better performance and concurrency control, isolation is divided by the ANSI SQL standard into levels that define the degree of locking when you select data. The four isolation levels are as follows (see also Table 13-5):

Every database management system has a default setting for the isolation level. You can change the default isolation level in the DBMS configuration. On JDBC, you can set the isolation level by using a property called hibernate.connection.isolation. Hibernate uses the following values to set a particular isolation level:

This setting is applicable only when the connection isn't obtained from an application server. In this scenario, you need to change the isolation level in the application server configuration.

Now, let's come back to the case of lost updates described at the beginning of this recipe (also in Table 13-1). You've seen a case where an update made by transaction 1 is lost when transaction 2 commits. Most applications are database connections with Read Committed isolation and use the optimistic concurrency control. One way of implementing optimistic control is to use versioning.

Hibernate provides automatic versioning. Each entity can have a version, which can be a number or a timestamp. Hibernate increments the number when the entity is modified. If you're saving with an older version (which is the case for transaction 2 in the lost-update problem), Hibernate compares the versions automatically and throws an exception.

To add a version number to an entity, you add a property called version of type int or Integer:

public class BookCh2 {
        private long isbn;
        private String name;
        private Date publishDate;
        private int price;
        private int version;
}

In the book.xml configuration file, you add the version element. Note that the version element must be placed immediately after the id element:

<hibernate-mapping package="com.hibernaterecipes.chapter2" auto-import="false" >
        <import class="BookCh2" rename="bkch2"/>
        <class name="BookCh2" table="BOOK" dynamic-insert="true" dynamic-update="true" schema="BOOK">
                <id name="isbn"  column="isbn" type="long">
                        <generator class="hilo">
                        </generator>
                </id>
                <version name="version" access="field" column="version"></version>
                <property name="name" type="string" column="BOOK_NAME" />
                <property name="publishDate" type="date" column="PUBLISH_DATE" />
                <property name="price" type="int" column="PRICE" />
        </class>
</hibernate-mapping>

A new column called version is created in the BOOK table. Using JPA, you add the version variable to the Book class and annotate it with the Version element:

@Entity (name="bkch2")
@org.hibernate.annotations.Entity(dynamicInsert = true, dynamicUpdate = true)
@Table        (name="BOOK")
public class BookCh2 {

        @Id
        @GeneratedValue (strategy=GenerationType.TABLE)
        @Column (name="ISBN")
        private long isbn;

        @Version
        @Column (name="version")
        private Integer version;

        @Column (name="book_Name")
        private String bookName;

        /*@Column (name="publisher_code")
        String publisherCode;*/

        @Column (name="publish_date")
        private Date publishDate;

        @Column (name="price")
        private Long price;
        // getters and setters
}

You can also use timestamps to version by adding a variable of type Date:

public class BookCh2 implements Serializable{
        private long isbn;
        private String name;
        private Date publishDate;
        private int price;
        private Date timestamp;
        // getters and setters
}

The XML mapping file has a timestamp element as shown here:

<hibernate-mapping package="com.hibernaterecipes.chapter2" auto-import="false" >
        <import class="BookCh2" rename="bkch2"/>
        <class name="BookCh2" table="BOOK" dynamic-insert="true" dynamic-update="true" schema="BOOK">
                <id name="isbn"  column="isbn" type="long">
                        <generator class="hilo">
                        </generator>
                </id>
                <timestamp name="timestamp" access="field" column="timestamp"></timestamp>
                <property name="name" type="string" column="BOOK_NAME" />
                <property name="publishDate" type="date" column="PUBLISH_DATE" />
                <property name="price" type="int" column="PRICE" />
        </class>
</hibernate-mapping>

You can also implement versioning without a version or timestamp by using the attribute optimistic-lock on the class mapping. It works when the entity is retrieved and modified in the same session. It doesn't work with detached objects. If you need to use optimistic concurrency control with detached objects, you must use a version or timestamp:

<hibernate-mapping package="com.hibernaterecipes.chapter2" auto-import="false" >
        <import class="BookCh2" rename="bkch2"/>
        <class name="BookCh2" table="BOOK" dynamic-insert="true" dynamic-update="true" schema="BOOK" optimistic-lock="all">
                <id name="isbn"  column="isbn" type="long">
                        <generator class="hilo">
                        </generator>
                </id>
                <property name="name" type="string" column="BOOK_NAME" />
                <property name="publishDate" type="date" column="PUBLISH_DATE" />
                <property name="price" type="int" column="PRICE" />
        </class>
</hibernate-mapping>

This isn't a popular option because it's slower and is complex to implement. In addition, JPA does not standardize this technique. So, if you need to use optimistic locking in JPA, you must use Hibernate's annotations, as shown here:

@Entity (name="bkch2")
@org.hibernate.annotations.Entity

(dynamicInsert = true, dynamicUpdate = true,
                 optimisticLock=org.hibernate.annotations.OptimisticLockType.ALL)
@Table        (name="BOOK")
public class BookCh2 {

        @Id
        @GeneratedValue (strategy=GenerationType.TABLE)
        @Column (name="ISBN")
        private long isbn;

        @Version
        @Column (name="version")
        private Integer version;

        @Column (name="book_Name")
        private String bookName;

        /*@Column (name="publisher_code")
        String publisherCode;*/

        @Column (name="publish_date")
        private Date publishDate;

        @Column (name="price")
        private Long price;
        // getters and setters
}

How do you implement pessimistic concurrency control in your application to save the book entity?

Most applications have Read Committed as the isolation level. This isolation level permits unrepeatable reads, which isn't desirable. One way to avoid unrepeatable reads is to implement versioning in the application. This upgrading of the isolation level from Read Committed to Repeatable Read comes with scalability issues. So, as an application developer, you may not want to make an application-wide upgrade to versioning—you may just want to upgrade the isolation level on a per-unit basis. To do so, Hibernate provides the lock() method in the Hibernate session object.

The following code demonstrates how an unrepeatable read can happen. You first get the book using session.get(), and then you use a query to read the name of the book. If an update happens between these two calls to the book's record in the database by a concurrent transaction, you have a case of unrepeatable reads:

Session session = getSession();
Transaction tx = null;
tx = session.beginTransaction();
BookCh2 book = (BookCh2)session.get(BookCh2.class, new Long(32769));
String name = (String) session.createQuery("select b.name from bkch2 b where b.isbn = :isbn")
                .setParameter("isbn", book.getIsbn()).uniqueResult();
System.out.println("BOOk's Name- "+name);
tx.commit();
session.close();

You can use session.lock to upgrade the isolation level. The previous code is updated as follows:

Session session = getSession();
Transaction tx = null;
tx = session.beginTransaction();
BookCh2 book = (BookCh2)session.get(BookCh2.class, new Long(32769));
session.lock(book, LockMode.UPGRADE);
String name = (String) session.createQuery("select b.name from bkch2 b where b.isbn = :isbn")
                .setParameter("isbn", book.getIsbn()).uniqueResult();
System.out.println("BOOk's Name- "+name);
tx.commit();
session.close();

Or you can directly call

BookCh2 book = (BookCh2)session.get(BookCh2.class, new Long(32769),LockMode.UPGRADE);

LockMode.UPGRADE creates a lock on the specific book record in the database. Now, other concurrent transactions can't modify the book record.

Hibernate supports the following lock modes: