Spring 3 Transaction Fundamentals (Declarative Annotation Based)
In this post I am going to provide some insight regarding Spring Transaction (Annotation bases: "@Transaction")
The Annotation based Spring Transaction can be configured in two modes:
1)proxy (default)
2)aspectj
and this can be configured through mode attribute of
Here I am going to discuss primarily regarding the proxy mode only.
There are two types of proxy used in Spring configuration:
1) Jdk dynamic Proxy.
2) Cglib Proxy.
Jdk dynamic Proxy: It is interface based proxy, and it is default configured as "proxy-target-class"
attribute of is false (by default).
The Proxy is created by implementing the interface
specified and then delegating the calls to the target object.
Cglib Proxy: It is class based proxy. The proxy is created by subclassing the target class.
It is used when "proxy-target-class" attribute of is set to true.
Each one has its own usage criteria Like
1) for legacy codes Cglib Proxy can be used.
2) If method of a class is final then Cglib Proxy will not bring that method into
Transaction Boundary while using Cglib Proxy so in that case Jdk Dynamic Proxy can be used.
and so there are other advantages and disadvantages too.
Now lets talk about some features of Spring proxy based Transaction.
1) If the bean name of the PlatformTransactionManager that we will be wiring in
in the transaction-manager attribute,
has the name transactionManager then no need of wiring is required ,
as then it is wired by default otherwise wiring is required.
This is Spring's CONVENTION OVER CONFIGURATION approach.
2) The Transaction annotation can be used over Interface definition, a method on the interface,
class definition, or a public method of the class.
The mere presence of the @Transaction annotation is simply not enough to enforce
Transaction boundary at the target place. It is merely a metadata which is consumed by Spring runtime
configuration who configured appropiate beans to implement this Transcational behaviour.
The " " switches on the Transcational behaviour.
3) Using @Transaction (proxy mode) annotation works only on methods having public visibility.
For any other visibility @Transaction does not implies any Transactional behaviour but no error is raised too.
In this cased Spring Transaction with aspectj mode is to be used.
4) SPRING recommends to use @Transaction annotation at the concrete class level.
Obviously it can also be used at the interface level, however using it at the interface level implies
that we want to use interface based proxies.
The fact that java annotations are not inherited from interface,
means that if we are using class based proxies where proxy-target-class="true"
then the transaction boundary will not be applied.
5) In Proxy mode only external calls coming in through the proxy are intercepted and falls under Transactional boundary.
This implies in case of self-invocation i.e. a method of a target object calling
another method of the target object will not come under Transactional boundary even if the invoked
method is marked @Transactional, because in the above scenario the invocation is proceeding
through the object itself not through the proxy and it is within
the Proxy that Transaction boundaries are defined.
6) In a Spring based application multiple context Files containing bean definitions can be used
and they are declared through ContextLoaderListener in web.xml of the application.
The configuration file which contains , all the beans in that file only whose
classes or interfaces has been annotated with @Transactional will be under Transaction Boundary
i.e. their proxy will be created (in Proxy mode).
7) A point to notice in case of Transaction Propagation behaviour with PROPAGATION_REQUIRED policy that a
logical transaction scope is created for each method upon which a setting is applied.
When a Transaction progresses from one method to another the Transaction boundary scope of former method to
the latter are logically independent but all such scopes are mapped to the same physical transaction.
For Ex. if method A() calls method B() under this Transaction policy then if method B() marks the Transaction as
rollback only then the enclosing method in A() will receive an UnexpectedRollbackException to indicate that method B()
is not committed instead a rollback is performed.
This is in short some salient features of Spring Transaction.
Any suggestions are always welcome. Please contribute to that, untill then happy reading and productive coding .
The Annotation based Spring Transaction can be configured in two modes:
1)proxy (default)
2)aspectj
and this can be configured through mode attribute of
Here I am going to discuss primarily regarding the proxy mode only.
There are two types of proxy used in Spring configuration:
1) Jdk dynamic Proxy.
2) Cglib Proxy.
Jdk dynamic Proxy: It is interface based proxy, and it is default configured as "proxy-target-class"
attribute of
The Proxy is created by implementing the interface
specified and then delegating the calls to the target object.
Cglib Proxy: It is class based proxy. The proxy is created by subclassing the target class.
It is used when "proxy-target-class" attribute of
Each one has its own usage criteria Like
1) for legacy codes Cglib Proxy can be used.
2) If method of a class is final then Cglib Proxy will not bring that method into
Transaction Boundary while using Cglib Proxy so in that case Jdk Dynamic Proxy can be used.
and so there are other advantages and disadvantages too.
Now lets talk about some features of Spring proxy based Transaction.
1) If the bean name of the PlatformTransactionManager that we will be wiring in
has the name transactionManager then no need of wiring is required ,
as then it is wired by default otherwise wiring is required.
This is Spring's CONVENTION OVER CONFIGURATION approach.
2) The Transaction annotation can be used over Interface definition, a method on the interface,
class definition, or a public method of the class.
The mere presence of the @Transaction annotation is simply not enough to enforce
Transaction boundary at the target place. It is merely a metadata which is consumed by Spring runtime
configuration who configured appropiate beans to implement this Transcational behaviour.
The "
3) Using @Transaction (proxy mode) annotation works only on methods having public visibility.
For any other visibility @Transaction does not implies any Transactional behaviour but no error is raised too.
In this cased Spring Transaction with aspectj mode is to be used.
4) SPRING recommends to use @Transaction annotation at the concrete class level.
Obviously it can also be used at the interface level, however using it at the interface level implies
that we want to use interface based proxies.
The fact that java annotations are not inherited from interface,
means that if we are using class based proxies where proxy-target-class="true"
then the transaction boundary will not be applied.
5) In Proxy mode only external calls coming in through the proxy are intercepted and falls under Transactional boundary.
This implies in case of self-invocation i.e. a method of a target object calling
another method of the target object will not come under Transactional boundary even if the invoked
method is marked @Transactional, because in the above scenario the invocation is proceeding
through the object itself not through the proxy and it is within
the Proxy that Transaction boundaries are defined.
6) In a Spring based application multiple context Files containing bean definitions can be used
and they are declared through ContextLoaderListener in web.xml of the application.
The configuration file which contains
classes or interfaces has been annotated with @Transactional will be under Transaction Boundary
i.e. their proxy will be created (in Proxy mode).
7) A point to notice in case of Transaction Propagation behaviour with PROPAGATION_REQUIRED policy that a
logical transaction scope is created for each method upon which a setting is applied.
When a Transaction progresses from one method to another the Transaction boundary scope of former method to
the latter are logically independent but all such scopes are mapped to the same physical transaction.
For Ex. if method A() calls method B() under this Transaction policy then if method B() marks the Transaction as
rollback only then the enclosing method in A() will receive an UnexpectedRollbackException to indicate that method B()
is not committed instead a rollback is performed.
This is in short some salient features of Spring Transaction.
Comments
Post a Comment