What does this mean ?

When a Multi Version Concurrency Control database (Oracle, Postgresql, MySQL + InnoDb) is used, a read only transaction can be translated to the non standard isolation level: READ_ONLY.

The READ_ONLY isolation level provides the same protection as the SERIALIZED isolation level (no dirty reads, no unrepeatable reads, no phantom reads) but doesn’t allow any updates. It also doesn’t cause any lock contention because no locking is required (the database is able to revert back to previous versions of the records ignoring all new changes).

Ms Sql 2005 also has a similar isolation level: SNAPSHOT.

If you specify readOnly as true, the flush mode will be set as FlushMode.NEVER in the current Hibernate Session preventing the session from committing the transaction.

Furthermore, setReadOnly(true) will be called on the JDBC Connection, which is also a hint to the underlying database. If your database supports it (most likely it does), this has basically the same effect as FlushMode.NEVER, but it’s stronger since you cannot even flush manually.

Now let’s see how transaction propagation works.

If you don’t explicitly set readOnly to true, you will have read/write transactions. Depending on the transaction attributes (like REQUIRES_NEW), sometimes your transaction is suspended at some point, a new one is started and eventually committed, and after that the first transaction is resumed.

If a method in a read/write transaction calls a method that requires a readOnly transaction, the first one should be suspended, because otherwise a flush/commit would happen at the end of the second method.

Conversely, if you call a method from within a readOnly transaction that requires read/write, again, the first one will be suspended, since it cannot be flushed/committed, and the second method needs that.

In the readOnly-to-readOnly, and the read/write-to-read/write cases the outer transaction doesn’t need to be suspended (unless you specify propagation otherwise, obviously).

This test in addition to Spring technical test / Spring Interview questions

This test will also help in Spring Certification exams

Update: A new test Core Spring Certification Mock has been added bu danielbutcher

We had service class which had transaction attributes defined in applicationContext.xml file as

<bean id=”helloService” parent=”txProxyTemplate”>

<property name=”target”>
<bean
class=”com.skillguru.impl.HelloServiceImpl”
autowire=”byName” />
</property>

<property name=”transactionAttributes”>
<props>
<prop key=”*”>PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>

Within the same file,  the transaction proxy template is defined as

<bean id=”txProxyTemplate” abstract=”true”
class=”org.springframework.transaction.interceptor.TransactionProxyFactoryBean”>
<property name=”transactionManager”>
<ref bean=”transactionManager” />
</property>
<property name=”transactionAttributes”>
<props>
<prop key=”save*”>PROPAGATION_REQUIRED</prop>
<prop key=”remove*”>PROPAGATION_REQUIRED</prop>
<prop key=”*”>PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>

The class HelloServiceImpl throws a User defined exception, UserDuplicateException

The logic is that a method HelloServiceImpl#saveUser inserts the user ina  aloop and then checks for duplicate user based on some coniftions.

If the user is duplicate , none of the records are to inserted.

This works fine on paper but not in real world. Reason being UserDuplicateException is  a user defined exception and not a an instance or subclass of RuntimeException, Spring was not rolling back the transaction.

Look at Spring docs here

For the transaction to roll back, the exception has to be configured like this

<bean id=”helloService” parent=”txProxyTemplate”>

<property name=”target”>
<bean

autowire=”byName” />
</property>

<property name=”transactionAttributes”>
<props>
<prop key=”*”>PROPAGATION_REQUIRED,-UserDuplicateException</prop>
</props>
</property>
</bean>

Look at -UserDuplicateException. This is the key here. For a user defined exception to rollback , you to have define it explicitly with a -ve sign.

Things have changed in newer version of Spring but the concept is still same.

Other Spring related posts

Spring Interview Questions

Which is better : Spring’s Transaction management or EJB’s Container managed transaction

Then came the Spring’s Transaction management feature which changed the way applications can manage transactions.  We will explore about Spring’s transactional capabilities and if they are better than EJB’s transaction

Spring provides two types of transaction

a)  Programmatic Transaction : This is used when developer would like to write the transaction related code himself

b) Declarative transaction :  This is enabled by Spring AOP and as the transactional aspects code comes with Spring and may be used in a boilerplate fashion

Most developers prefer declarative transaction as it has least impact on application code

Feature of Spring Transaction :

• Spring Framework’s declarative transaction management is not tied to JTA therefore works in any environment. It can work with JDBC, JDO, Hibernate or other transactions under the covers, with configuration changes only.

For eg in this class below

}

public class RecordHibernateDAO implements RecordsDAO {

public void addRecords(Records record ){

//do something

}

We can mange the transaction by adding this annotation for the method addrecords

@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)

}

public void addRecords(Records record ){

//do something

• The Spring Framework enables declarative transaction management to be applied to any class, not merely special classes such as EJBs. For eg in the above example instead of HibernateDAO class we could have a plain java class on which transaction capabilities can be applied. This makes life so much easy for an application developer. Now he is not constrained by “business logic” residing inside EJB only.

• The Spring Framework offers declarative rollback rules: this is a feature with no EJB equivalent. Both programmatic and declarative support for rollback rules is provided. This especially comes handy when you want transaction to be rolled back for certain exceptions only.

• The Spring Framework gives you an opportunity to customize transactional behavior, using AOP. For example, if you want to insert custom behavior in the case of transaction rollback, you can. You can also add arbitrary advice, along with the transactional advice. With EJB CMT, you have no way to influence the container’s transaction management other than setRollbackOnly().

• The Spring Framework does not support propagation of transaction contexts across remote calls, as do high-end application servers. EJB is much better suited for this.

After having said all this , you can clearly decide which one is better. I went with Spring transactions because it gives me the ability to manage transaction decoratively with out having to bear the additional overhead of an Application server