Hibernate Transactions - Part 1 - How to Wrap...

Just had a call from someone wanting to know how to use Hibernate to delete some data from a table. Hibernate is extremely powerful when transactions are used correctly. First of all, lets start with where to "wrap" the transactions...

Most J2EE architecture is built like this (or should be!):

1. Actions (Struts)
2. Services
3. DAOs (Data access objects)

One minor note is that Actions should NEVER have DAOs in them.  No reason.  Never.  The question you should have in the coding of any action is this.  "If I want to do this in the action, will I need to recode if I want to add a REST service to do this?"  Let me explain.  If you put ALL business logic and database calls in the Service layer, it is nothing to put a REST service to access it.  If you put DAO calls (or any business logic) in the Actions, you will have to cut and paste that code into a service to put a REST service on the same logic.  The following is brilliant service code!

public List getAllActiveLegacyFeatures() throws Exception {
  List features = fpsDao.grabAllActiveLegacyFeatures();
  return features;
 }

Moving on.  So you really only have 2 choices.  Wrap the transactions at the DAO layer or the Service layer. Lets begin by showing you how to "Wrap" a transaction.  Here is some code that does it:

<bean id="ImportKeyDataServiceImplementation" class="cat.dds.fpsdma.services.ImportKeyDataService">
  <constructor-arg index="0" ref="fpsDAO" />
 </bean>
 <bean id="ImportKeyDataService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
  <property name="transactionManager">
   <ref bean="theTransactionManager" />
  </property>
  <property name="target">
   <ref local="ImportKeyDataServiceImplementation" />
  </property>
  <property name="transactionAttributes">
   <props>
    <prop key="*">PROPAGATION_REQUIRED</prop>
   </props>
  </property>
 </bean>

The first "bean" here is the actual object. Notice that on line 2 it has a DAO. Now this object should never be used, so we actually call it an "...Implementation". Notice that the second bean is named "ImportKeyDataService" It is not an implementation, but the object that we should use. (This is just how we did it on FPS. We just used this naming convention so we new that we should never use the "Implementation" objects). Notice that the Implementation object is referenced on line 9. This ties all this together. So, when you actually use the object "ImportKeyDataService" you will get a Wrapped transaction.

What does this give you? Lots. When any DAO call is made in the ImportKeyDataService object above, Hibernate will not commit anything. Batch updates and such automatically roll back correctly if there is an error thrown out of the ImportKeyDataService object. This would not happen if you wrapped the DAO. Every time you go in and back out of an object (the object looses scope) you commit. So, if you have a DAO doing something, it would commit every time you made a call.

Now there are two times when you want the DAO to be wrapped.

1. If you are doing DB2 calls to CDID or some alien database, and you are just doing "selects", it is best to commit after every transaction.  For some reason Mainframers like that.
2. JUnits usually require commits to work properly.  We make a junit for EVERY database call.  They just don't work if you don't commit after each one.  However, in this case, Spring makes this easy.

The most powerful thing about Wrapping transactions, though, is the "Lazy" fetching.  I will talk about that in the next post...