Delayed Consistency Validation in Hibernate

1.                         Delayed Consistency Validation in Hibernate

1.1.                  Abstract

There are occasions when the consistency of updates being done on the database needs to be deferred till the point just before the commit. A situation similar to this occurred for one of our client where the consistency of the relationship between entities was to be checked. It is very obvious that the update on the entities participating in the relationship can occur in any order or may not occur at all. Therefore the check needs to be performed just before the commit when all updated have happened.

One simple solution to check the consistency is to create database triggers which perform the consistency checks. This approach has its own drawback which business logic getting spread across the Application Tier and the Database Tier in a typical application. For the same reason, this was not a preferred approach of the client too.

A solution with hibernate of using Interceptors was also ruled out due to the technology stack being used. The entities being EMF objects required use of Teneo which uses the interceptors and replaces any configured interceptor defined on the Entity.

1.2.                  Solution

To attack the problem at hand, two very probable directions left were the JDBCContext class and the JEE Synchronization interface.

Hibernate uses a class called the JDBCContext to perform any operations on the database resources. The class has methods which get invoked at start of transaction, and before and after the completion of the transaction. This could have lead to a solution of having a custom JDBCContext class, but was ruled out as hibernate does not provide any hooks to use a different class instead of class it provides.

The JEE Transaction (javax.transaction.Transaction) interface as well as the Hibernate Transaction (org.hibernate.Transaction) interface both use the JEE Synchronization (javax.transaction.Synchronization) interface for notifying the transaction before completion and after completion events. JEE Synchronization being a very light weight object, attaching multiple synchronizations to a transaction was also feasible. The transaction in Hibernate (implementation of Hibernate Transaction interface) is created using a transaction factory (org.hibernate.transaction.TransactionFactory interface) which can be configured very easily in Hibernate.

The solution uses delegation very effectively to achieve the desired result. Following classes were used in the solution

DelegateTransactionFactory

a.            Implements the org.hibernate.transaction.TransactionFactory interface.

b.           Configures the actual factory uses the properties to do the same.

c.            The createTransaction method returns the transaction returned by the actual factory wrapped in the new DelegateTransaction class.

d.           Other methods simply delegate to the actual factory.

e.            This class is configured as the factory_class in the Hibernate configuration with the actual factory as its sub property.

DelegateTransaction

a.       Interestingly this class would not have been required had the JDBC Transaction class (org.hibernate.transaction.JDBCTransaction) been implemented correctly in Hibernate. This class ignores the exception thrown by the JEE Synchronization totally ignoring the JEE specifications recommendation.

b.      Implements the org.hibernate.Transaction interface.

c.       Methods simply delegate to the actual transaction barring the corrections required for first point above.

EntitySynchronization

a.       Implements the javax.transaction.Synchronization interface.

b.      Constructed using entity as an argument

c.       Calls the relationship validation methods on the entity in the implementation of the before transaction completion callback. This is done when the transaction is not rolling back.

d.      Performs the cleaning up operation in the after transaction completion callback.

e.       The actual checks are modeled and there code is generated using MDA

1.3.                  Other Solutions

Two other possible solutions which could have been tried out are the following

1.      Using dynamic proxy to create a delegate class for JDBCContext class and overriding the implements of before and after the completion of the transaction callbacks.

2.      Create a composite Interceptor and ensure that the Teneo’s interceptor is the last to be called in the Composite Interceptor.