Declarative transaction management - Java-Springs

The Spring Framework's declarative transaction management is made possible with Spring aspect-oriented programming (AOP), although, as the transactional aspects code comes with the Spring Framework distribution and may be used in a boilerplate fashion, AOP concepts do not generally have to be understood to make effective use of this code.

The Spring Framework's declarative transaction management is similar to EJB CMT in that you can specify transaction behavior (or lack of it) down to individual method level.It is possible to make a setRollbackOnly() call within a transaction context if necessary. The differences between the two types of transaction management are:

  • Unlike EJB CMT, which is tied to JTA, the Spring Framework's declarative transaction management works in any environment. It can work with JTA transactions or local transactions using JDBC, JPA, Hibernate or JDO by simply adjusting the configuration files.
  • You can apply the Spring Framework declarative transaction management to any class, not merely special classes such as EJBs.
  • The Spring Framework offers declarative rollback rules, a feature with no EJB equivalent. Both programmatic and declarative support for rollback rules is provided.
  • The Spring Frame work enables you to customize transactional behavior, by using AOP. For example, you can insert custom behavior in the case of transaction rollback. You can also add arbitrary advice, along with the transactional advice. With EJB CMT, you cannot influence the container's transaction management except with setRollbackOnly().
  • The Spring Frame work does not support propagation of transaction contexts across remote calls, as do high-end application servers. If you need this feature, we recommend that you use EJB. However, consider carefully before using such a feature, because normally, one does not want transactions to span remote calls.

Where is TransactionProxyFactoryBean?

Declarative transaction configuration in versions of Spring 2.0 and above differs considerably from previous versions of Spring. The main difference is that there is no longer any need to configure Transaction Proxy Factory Bean beans.

The pre-Spring 2.0 configuration style is still 100% valid configuration; think of the new <tx:tags/> as simply defining Transaction Proxy Factory Bean beans on your behalf. The concept of rollback rules is important: they enable you to specify which exceptions (and throwables) should cause automatic rollback. You specify this declaratively, in configuration, not in Java code. So, although you can still call set Roll back Only()on the Transaction tatus object to roll back the current transaction back, most often you can specify a rule that MyApplicationException must always result in rollback. The significant advantage to this option is that business objects do not depend on the transaction infrastructure. For example, they typically do not need to import Spring transaction APIs or other Spring APIs.

Although EJB container default behavior automatically rolls back the transaction on a system exception (usually a runtime exception), EJB CMT does not roll back the transaction automatically on an application exception (that is, a checked exception other than java.rmi.Remote Exception). Whilethe Spring default behavior for declarative transaction management follows EJB convention (roll back isautomatic only on unchecked exceptions), it is often useful to customize this behavior.

Understanding the Spring Frame work's declarative transaction implementation

It is not sufficient to tell you simply to annotate your classes with the @Transactional annotation, add the line (<tx:annotation-driven/>) to your configuration, and then expect you to understand how it all works.

The most important concepts to grasp with regard to the Spring Framework's declarative transaction support are that this support is enabled via AOP proxies, and that the transactional advice is driven by metadata (currently XML- or annotation-based). The combination of AOP with transactional metadata yields an AOP proxy that uses a Transaction Interceptor in conjunction with an appropriate Platform Transaction Manager implementation to drive transactions around method invocations.


Example of declarative transaction implementation

Consider the following interface, and its attendant implementation. This example uses Foo and Bar classes as place holders so that you can concentrate on the transaction usage without focusing on a particular domain model. For the purposes of this example, the fact that the DefaultFooService class throws Un supported Operation Exception instances in the body of each implemented method is good; it allows you to see transactions created and then rolled back in response to the Unsupported Operation Exception instance.

// the service interface that we want to make transactional
package x.y.service;
public interface FooService {
Foo getFoo(String fooName);
Foo getFoo(String fooName, String barName);
void insertFoo(Foo foo);
void updateFoo(Foo foo);
// an implementation of the above interface
package x.y.service;
public class DefaultFooService implements FooService {
public Foo getFoo(String fooName) {
throw new UnsupportedOperationException();
public Foo getFoo(String fooName, String barName) {
throw new UnsupportedOperationException();
public void insertFoo(Foo foo) {
throw new UnsupportedOperationException();
public void updateFoo(Foo foo) {
throw new UnsupportedOperationException();

Assume that the first two methods of the FooService interface, get Foo(String) and getFoo(String, String), must execute in the context of a transaction with read-only semantics, and that the other methods,insertFoo(Foo) and update Foo(Foo), must execute in the context of a transaction with read-write semantics.

Examine the preceding configuration. You want to make a service object, the for Service bean, transactional.The transaction semantics to apply are encapsulated in the <tx:advice/> definition.The <tx:advice/> definition reads as “... all methods on starting with 'get' are to execute in the context of a read-only transaction, and all other methods are to execute with the default transaction semantics”.

The transaction-manager attribute of the <tx:advice/> tag is set to the name of the Platform Transaction Manager bean that is going to drive the transactions, in this case, the txManager bean.

The <aop:config/> definition ensures that the transactional advice defined by the txAdvice bean executes at the appropriate points in the program. First you define a pointcut that matches the execution of any operation defined in the FooService interface (foo Service Operation). Then you associate the pointcut with the txAdvice using an advisor. The result indicates that at the execution of a foo Service Operation, the advice defined by txAdvice will be run.

A common requirement is to make an entire service layer transactional. The best way to do this is simply to change the pointcut expression to match any operation in your service layer. For example:

<aop:pointcut id="fooServiceMethods" expression="execution(* x.y.service.*.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceMethods"/>

Now that we've analyzed the configuration, you may be asking yourself, “Okay... but what does all this configuration actually do?”.

The above configuration will be used to create a transactional proxy around the object that is created from the foo Service bean definition. The proxy will be configured with the transactional advice, so that when an appropriate method is invoked on the proxy, a transaction is started, suspended, marked as read-only, and so on, depending on the transaction configuration associated with that method. Consider the following program that test drives the above configuration:

public final class Boot {
public static void main(final String[] args) throws Exception {
ApplicationContext ctx = new ClassPathXmlApplicationContext("context.xml", Boot.class);
FooService fooService = (FooService) ctx.getBean("fooService");
fooService.insertFoo (new Foo());

The output from running the preceding program will resemble the following. (The Log4J output and the stack trace from the Uns upported Operation Exception thrown by the insertFoo(..) method of the Default FooS ervice class have been truncated for clarity.)

<!-- the Spring container is starting up... -->
[AspectJInvocationContextExposingAdvisorAutoProxyCreator] - Creating implicit proxy
for bean 'fooService' with 0 common interceptors and 1 specific interceptors
<!-- the DefaultFooService is actually proxied -->
[JdkDynamicAopProxy] - Creating JDK dynamic proxy for [x.y.service.DefaultFooService]
<!-- ... the insertFoo(..) method is now being invoked on the proxy -->
[TransactionInterceptor] - Getting transaction for x.y.service.FooService.insertFoo
<!-- the transactional advice kicks in here... -->
[DataSourceTransactionManager] - Creating new transaction with name
[DataSourceTransactionManager] - Acquired Connection
[org.apache.commons.dbcp.PoolableConnection@a53de4] for JDBC transaction
<!-- the insertFoo(..) method from DefaultFooService throws an exception... -->
[RuleBasedTransactionAttribute] - Applying rules to determine whether transaction should
rollback on java.lang.UnsupportedOperationException
[TransactionInterceptor] - Invoking rollback for transaction on
due to throwable [java.lang.UnsupportedOperationException]
<!-- and the transaction is rolled back (by default,
RuntimeException instances cause rollback) --
[DataSourceTransactionManager] - Rolling back JDBC transaction on Connection
[DataSourceTransactionManager] - Releasing JDBC Connection after transaction
[DataSourceUtils] - Returning JDBC Connection to DataSource
Exception in thread "main" java.lang.UnsupportedOperationException
at x.y.service.DefaultFooService.insertFoo(
<!-- AOP infrastructure stack trace elements removed for clarity -->
at $Proxy0.insertFoo(Unknown Source)
at Boot.main(

Rolling back a declarative transaction

The recommended way to indicate to the Spring Framework's transaction infra structure that a transaction's work is to be rolled back is to throw an Exception from code that is currently executing in the context of a transaction.The Spring Frame work's transaction infrastructure code will catch any un handled Exception as it bubbles up the call stack, and make a determination whether to mark the transaction for rollback.

In its default configuration, the Spring Frame work's transaction infrastructure code only marks a transaction for rollback in the case of runtime, unchecked exceptions; that is, when the thrown exception is an instance or subclass of RuntimeException. (Errors will also - by default - result in a rollback). Checkedexceptions that are thrown from a transactional method do not result in rollback in the default configuration.

You can configure exactly which Exception types mark a transaction for rollback, including checked exceptions. The following XML snippet demonstrates how you configure rollback for a checked, application-specific Exception type.

<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:method name="get*" read-only="true" rollback-for="NoProductInStockException"/>
<tx:method name="*"/>

You can also specify 'no rollback rules', if you do not want a transaction rolled back when an exception is thrown. The following example tells the Spring Framework's transaction infrastructure to commit the attendant transaction even in the face of an unhandled InstrumentNot Found Exception.

<tx:advice id="txAdvice">
<tx:method name="updateStock" no-rollback-for="InstrumentNotFoundException"/>
<tx:method name="*"/>

When the Spring Framework's transaction infrastructure catches an exception and is consults configured rollback rules to determine whether to mark the transaction for rollback, the strongest matching rule wins.So in the case of the following configuration, any exception other than an InstrumentNot Found Exception results in a rollback of the attendant transaction.

<tx:advice id="txAdvice">
<tx:method name="*" rollback-for="Throwable" no-rollback-for="InstrumentNotFoundException"/>

You can also indicate a required rollback programmatically. Although very simple, this process is quite invasive, and tightly couples your code to the Spring Framework's transaction infrastructure:

public void resolvePosition() {
try {
// some business logic...
} catch (NoProductInStockException ex) {
// trigger rollback programmatically

You are strongly encouraged to use the declarative approach to rollback if at all possible. Programmatic rollback is available should you absolutely need it, but its usage flies in the face of achieving a clean POJO-based architecture.

Configuring different transactional semantics for different beans

Consider the scenario where you have a number of service layer objects, and you want to apply a totally different transactional configuration to each of them.You do this by defining distinct <aop:advisor/> elements with differing pointcut and advice-ref attribute values.

As a point of comparison, first assume that all of your service layer classes are defined in a root x.y.service package.To make all beans that are instances of classes defined in that package (or in subpackages) and that have names ending in Service have the default transactional configuration,

<tx:advice/> settings

This summarizes the various transactional settings that can be specified using the <tx:advice/> tag. The default <tx:advice/> settings are:

  • Propagation setting is REQUIRED.
  • Isolation level is DEFAULT.
  • Transaction is read/write.
  • Transaction timeout defaults to the default timeout of the underlying transaction system, or none if timeouts are not supported.
  • Any RuntimeException triggers rollback, and any checked Exception does not.

You can change these default settings; the various attributes of the <tx:method/> tags that are nested within <tx:advice/> and <tx:attributes/> tags are summarized below:

Table :- <tx:method/> settings


Using @Transactional

In addition to the XML-based declarative approach to transaction configuration, you can use an annotation-based approach. Declaring transaction semantics directly in the Java source code puts the declarations much closer to the affected code.There is not much danger of undue coupling, because code that is meant to be used transactionally is almost always deployed that way anyway.

The ease-of-use afforded by the use of the @Transactional annotation is best illustrated with an example, which is explained in the text that follows. Consider the following class definition:

// the service class that we want to make transactional
public class DefaultFooService implements FooService {
Foo getFoo(String fooName);
Foo getFoo(String fooName, String barName);
void insertFoo(Foo foo);
void updateFoo(Foo foo);

method visibility and @Transactional

When using proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do annotate protected, private or package-visible methods with the @Transactional annotation, no error is raised, but the annotated method does not exhibit the configured transactional settings. Consider the use of AspectJ (see below) if you need to annotate non-public methods.

You can place the @Transactional annotation before an interface definition, a method on an interface, a class definition, or a public method on a class. However, the mere presence of the @Transactional annotation is not enough to activate the transactional behavior.The @Transactional annotation is simply metadata that can be consumed by some runtime infrastructure that is @Transactional-aware and that can use the metadata to configure the appropriate beans with transactional behavior.In the preceding example, the <tx:annotation-driven/> element switcheson the transactional behavior.

Consider the use of AspectJ mode (see mode attribute in table below) if you expect self-invocations to be wrapped with transactions as well. In this case, there will not be a proxy in the first place; instead, the target class will be weaved (that is, its byte code will be modified) in order to turn @Transactional into runtime behavior on any kind of method.

Table :-<tx:annotation-driven/> settings

tx annotation driven settingstx annotation driven settings

The most derived location takes precedence when evaluating the transactional settings for a method. In the case of the following example, the DefaultFooService class is annotated at the class level with the settings for a read-only transaction, but the @Transactional annotation on the up date Foo(Foo) method in the same class takes precedence over the transactional settings defined at the class level.

@Transactional(readOnly = true)
public class DefaultFooService implements FooService {
public Foo getFoo(String fooName) {
// do something
// these settings have precedence for this method
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void updateFoo(Foo foo) {
// do something

Transactional settings

The @Transactional annotation is metadata that specifies that an interface, class, or method must have transactional semantics; for example, “start a brand new read-only transaction when this method isinvoked, suspending any existing transaction”.The default @Transactional settings are as follows:

  • Propagation setting is PROPAGATION_REQUIRED.
  • Isolation level is ISOLATION_DEFAULT.
  • Transaction is read/write.
  • Transaction timeout defaults to the default timeout of the underlying transaction system, or to none if timeouts are not supported.
  • Any RuntimeException triggers rollback, and any checked Exception does not.

These default settings can be changed; the various properties of the @Transactional annotation are summarized in the following table:

Table:-@Transactional properties

Transactional propertiesTransactional properties

Currently you cannot have explicit control over the name of a transaction, where 'name' means the transaction name that will be shown in a transaction monitor, if applicable (for example, WebLogic's transaction monitor), and in logging output.For declarative transactions, the transaction name is always the fully-qualified class name + "." + method name of the transactionally-advised class. For example, if the handlePayment(..) method of the Business Service class started a transaction, the name of the transaction would be: BusinessService. handlePayment.

Multiple Transaction Managers with @Transactional

Most Spring applications only need a single transaction manager, ut there may be situations where you want multiple independent transaction managers in a single application. The value attribute of the @Transactional annotation and be used to optionally specify the identity of the PlatformTransactionManager to be used. This can either be the bean name or the qualifier value of the transaction manager bean.For example, using the qualifier notation, the following Java code

public class TransactionalService {
public void setSomething(String name) { ... }
public void doSomething() { ... }

could be combined with the following transaction manager bean declarations in the application context.

<bean id="transactionManager1" class="org.springframework.jdbc.DataSourceTransactionManager">
<qualifier value="order"/>
<bean id="transactionManager2" class="org.springframework.jdbc.DataSourceTransactionManager">
<qualifier value="account"/>

In this case, the two methods on Transactional Service will run under separate transaction managers, differentiated by the "order" and "account" qualifiers. The default <tx:annotation-driven> target bean name transaction Manager will still be used if no specifically qualified Plat form Transaction Manager bean is found.

Custom shortcut annotations

If you find you are repeatedly using the same attributes with @Transactional on many different methods, then Spring's meta-annotation support allows you to define custom shortcut annotations for your specific use cases. For example, defining the following annotations.

@Target({ElementType.METHOD, ElementType.TYPE})
public @interface OrderTx {
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface AccountTx {
public class TransactionalService {
public void setSomething(String name) { ... }
public void doSomething() { ... }

Here we have used the syntax to define the transaction manager qualifier, but could also have included propagation behavior, rollback rules, timeouts etc.

Transaction propagation

This describes some semantics of transaction propagation in Spring. Please note that this is not an introduction to transaction propagation proper; rather it details some of the semantics regarding transaction propagation in Spring.

In Spring-managed transactions, be aware of the difference between physical and logical transactions, and how the propagation setting applies to this difference.



PROPAGATION_REQUIRED When the propagation setting is PROPAGATION_REQUIRED, a logical transaction scope is created for each method upon which the setting is applied. Each such logical transaction scope can determine rollback-only status individually, with an outer transaction scope being logically independent from the inner transaction scope. Of course, in case of standard PROPAGATION_REQUIRED behavior,all these scopes will be mapped to the same physical transaction. So a rollback-only marker set in the inner transaction scope does affect the outer transaction's chance to actually commit (as you would expect it to).
However, in the case where an inner transaction scope sets the rollback-only marker, the outer transaction has not decided on the rollback itself, and so the rollback (silently triggered by the inner transaction scope) is unexpected. A corresponding UnexpectedRollbackException is thrown at that point.

This is expected behavior so that the caller of a transaction can never be misled to assume that a commit was performed when it really was not. So if an inner transaction (of which the outer caller is not aware) silently marks a transaction as rollback-only, the outer caller still calls commit. The outer caller needs to receive an Un expected Roll back Exception to indicate clearly that a rollback was performed instead.


Requires New

PROPAGATION_REQUIRES_NEW PROPAGATION_REQUIRES_NEW, in contrast to PROPAGATION_ REQUIRED, uses a completely independent transaction for each affected transaction scope. In that case, the underlying physical transactions are different and hence can commit or roll back independently, with an outer transaction notaffected by an inner transaction's rollback status.


PROPAGATION_NESTED uses a single physical transaction with multiple savepoints that it can roll back to.Such partial rollbacks allow an inner transaction scope to trigger a rollback for its scope, with the outer transaction being able to continue the physical transaction despite some operations having been rolled back. This setting is typically mapped onto JDBC savepoints, so will only work with JDBC resource transactions. See Spring's Data Source Transaction Manager.

Advising transactional operations

Suppose you want to execute both transactional and some basic profiling advice. How do you effect this in the context of <tx:annotation-driven/>?

When you invoke the updateFoo(Foo) method, you want to see the following actions:

  1. Configured profiling aspect starts up.
  2. Transactional advice executes.
  3. Method on the advised object executes.
  4. Transaction commits.
  5. Profiling aspect reports exact duration of the whole transactional method invocation.

Here is the code for a simple profiling aspect. The ordering of advice is controlled through the Ordered interface.

package x.y;
import org.aspectj.lang.ProceedingJoinPoint;
import org.springframework.util.StopWatch;
import org.springframework.core.Ordered;
public class SimpleProfiler implements Ordered {
private int order;
// allows us to control the ordering of advice
public int getOrder() {
return this.order;
public void setOrder(int order) {
this.order = order;
// this method is the around advice
public Object profile(ProceedingJoinPoint call) throws Throwable {
Object returnValue;
StopWatch clock = new StopWatch(getClass().getName());
try {
returnValue = call.proceed();
} finally {
return returnValue;

The result of the above configuration is a foo Service bean that has profiling and transactional aspects applied to it in the desired order. You configure any number of additional aspects in similar fashion. The following example effects the same setup as above,

The result of the above configuration will be a foo Service bean that has profiling and transactional aspects applied to it in that order.If you want the profiling advice to execute after the transactional advice on the way in, and before the transactional advice on the way out, then you simply swap the value of the profiling aspect bean's order property so that it is higher than the transactional advice's order value.

You configure additional aspects in similar fashion.

Using @Transactional with AspectJ

It is also possible to use the Spring Framework's @Transactional support outside of a Spring container by means of an AspectJ aspect. To do so, you first annotate your classes (and optionally your classes' methods) with the @Transactional annotation, and then you link (weave) your application with the org. spring framework. transaction. aspectj. Annotation Transaction Aspect defined in the spring-aspects.jar file.The aspect must also be configured with a transaction manager. You can of course use the Spring Frame work's IoC container to take care of dependency-injecting the aspect. The simplest way to configure the transaction management aspect is to use the <tx:annotation-driven/> element and specify the mode attribute to aspectj. Because we're focusing here on applications running outside of a Spring container, we'll show you how to do it programmatically.

// construct an appropriate transaction manager
DataSourceTransactionManager txManager = new DataSourceTransactionManager(getDataSource());
// configure the AnnotationTransactionAspect to use it;
this must be done before executing any transactional methods


The @Transactional annotation on a class specifies the default transaction semantics for the execution of any method in the class.

The @Transactional annotation on a method within the class overrides the default transaction semantics given by the class annotation (if present). Any method may be annotated, regardless of visibility.

To weave your applications with the Annotation Transaction Aspect you must either build your application with AspectJ (see the AspectJ Development Guide) or use load-time weaving.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Java-Springs Topics