Spring Transaction Management:
@Transactional In-Depth
Introduction
How plain JDBC Transaction Management works
How Spring’s or Spring Boot’s Transaction Management
works
How Spring and JPA / Hibernate Transaction Management
works
Fin
Acknowledgements
You can use this guide to get a simple and practical
understanding of how Spring's transaction management with
the @Transactional annotation works.
The only prerequisite? You need to have a rough idea about
ACID, i.e. what database transactions are and why to use
them. Also, distributed transactions or reactive transactions
are not covered here, though the general principles, in terms of
Spring, still apply.
Introduction
In this guide you are going to learn about the main pillars
of Spring core’s transaction abstraction framework (a
confusing term, isn’t it?) - described with a lot of code
examples:
@Transactional (Declarative Transaction Management) vs
Programmatic Transaction Management.
Physical vs Logical transactions.
Spring @Transactional and JPA / Hibernate integration.
Spring @Transactional and Spring Boot or Spring MVC
integration.
Rollbacks, Proxies, Common Pitfalls and much more.
As opposed to, say, the official Spring documentation, this
guide won’t confuse you by diving right into the topic Spring-
first.
Instead you are going to learn Spring transaction management
the unconventional way: From the ground up, step by step.
This means, starting with plain old JDBC
transaction management.
Why?
Because everything that Spring does is based on these very
JDBC basics. And you’ll save a ton of time with Spring’s
@Transactional annotation later, if you grasp these basics.
How plain JDBC Transaction Management works
If you are thinking of skipping this section, without knowing
JDBC transactions inside-out: don’t.
How to start, commit or rollback JDBC transactions
The first important take-away is this: It does not matter if you
are using Spring’s @Transactional annotation, plain Hibernate,
jOOQ or any other database library.
In the end, they all do the very same thing to open and close
(let’s call that 'manage') database transactions. Plain JDBC
transaction management code looks like this:
import java.sql.Connection;
Connection connection = dataSource.getConnection(); // (1)
try (connection) {
connection.setAutoCommit(false); // (2)
// execute some SQL statements...
connection.commit(); // (3)
} catch (SQLException e) {
connection.rollback(); // (4)
1. You need a connection to the database to start
transactions. DriverManager.getConnection(url, user,
password) would work as well, though in most enterprise-y
applications you will have a data source configured and get
connections from that.
2. This is the only way to start a database transaction in
Java, even though the name might sound a bit
off. setAutoCommit(true) wraps every single SQL
statement in its own transaction
and setAutoCommit(false) is the opposite: You are the
master of the transaction.
3. Let’s commit our transaction…
4. Or, rollback our changes, if there was an exception.
Yes, these 4 lines are (oversimplified) everything that Spring
does whenever you are using the @Transactional annotation. In
the next chapter you’ll find out how that works. But before we
go there, there’s a tiny bit more you need to learn.
(A quick note for smarty-pants: Connection pool libraries
like HikariCP might toggle the autocommit mode
automatically for you, depending on the configuration. But that
is an advanced topic.)
How to use JDBC isolation levels and savepoints
If you already played with Spring’s @Transactional annotation
you might have encountered something like this:
@Transactional(propagation=TransactionDefinition.NESTED,
isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED)
We will cover nested Spring transactions and isolation levels
later in more detail, but again it helps to know that these
parameters all boil down to the following, basic JDBC code:
import java.sql.Connection;
// isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED
connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED); // (1)
// propagation=TransactionDefinition.NESTED
Savepoint savePoint = connection.setSavepoint(); // (2)
...
connection.rollback(savePoint);
1. This is how Spring sets isolation levels on a database
connection. Not exactly rocket science, is it?
2. Nested transactions in Spring are just JDBC / database
savepoints. If you don’t know what a savepoint is, have a
look at this tutorial, for example. Note that savepoint
support is dependent on your JDBC driver/database.
Recommended: Practice JDBC basics
You can find a ton of code examples and exercises on plain
JDBC connections and transactions in the Plain JDBC chapter
of this Java database e-book.
How Spring’s or Spring Boot’s Transaction
Management works
As you now have a good JDBC transaction understanding, let’s
have a look at how plain, core Spring manages transactions.
Everything here applies 1:1 to Spring Boot and Spring MVC,
but more about that a bit later..
What actually is Spring’s transaction management or its
(rather confusingly named) transaction abstraction
framework?
Remember, transaction management simply means: How does
Spring start, commit or rollback JDBC transactions? Does this
sound in any way familiar from above?
Here’s the catch: Whereas with plain JDBC you only have one
way (setAutocommit(false)) to manage transactions, Spring
offers you many different, more convenient ways to achieve
the same.
How to use Spring’s Programmatic Transaction Management?
The first, but rather sparingly used way to define transactions
in Spring is programmatically: Either through a
TransactionTemplate or directly through the
PlatformTransactionManager. Code-wise, it looks like this:
@Service
public class UserService {
@Autowired
private TransactionTemplate template;
public Long registerUser(User user) {
Long id = template.execute(status -> {
// execute some SQL that e.g.
// inserts the user into the db and returns the autogenerated id
return id;
});
Compared with the plain JDBC example:
You do not have to mess with opening or closing database
connections yourself (try-finally). Instead you
use Transaction Callbacks.
You also do not have to catch SQLExceptions, as Spring
converts these exceptions to runtime exceptions for you.
And you have better integration into the Spring
ecosystem. TransactionTemplate will use a
TransactionManager internally, which will use a data
source. All are beans that you have to specify in your
Spring context configuration, but then don’t have to worry
about anymore later on.
While this counts as a minor improvement, programmatic
transaction management is not what Spring’s transaction
framework mainly is about. Instead, it’s all about declarative
transaction management. Let’s find out what that is.
How to use Spring’s XML Declarative Transaction
Management?
Back in the day, when XML configuration was the norm for
Spring projects, you could configure transactions directly in
XML. Apart from a couple of legacy, enterprise projects, you
won’t find this approach anymore in the wild, as it has been
superseded with the much simpler @Transactional annotation.
We will not go into detail on XML configuration in this guide,
but you can use this example as a starting point to dive deeper
into it - if needed (taken straight from the official Spring
documentation):
<!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean below)
-->
<tx:advice id="txAdvice" transaction-manager="txManager">
<!-- the transactional semantics... -->
<tx:attributes>
<!-- all methods starting with 'get' are read-only -->
<tx:method name="get*" read-only="true"/>
<!-- other methods use the default transaction settings (see below) -->
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
You are specifying an AOP advice (Aspect Oriented
Programming) with the above XML block, that you can then
apply to your UserService bean like so:
<aop:config>
<aop:pointcut id="userServiceOperation" expression="execution(*
x.y.service.UserService.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="userServiceOperation"/>
</aop:config>
<bean id="userService" class="x.y.service.UserService"/>
Your UserService bean would then look like this:
public class UserService {
public Long registerUser(User user) {
// execute some SQL that e.g.
// inserts the user into the db and retrieves the autogenerated id
return id;
}
}
From a Java code perspective, this declarative transaction
approach looks a lot simpler than the programmatic approach.
But it leads to a lot of complicated, verbose XML, with the
pointcut and advisor configurations.
So, this leads to the question: Is there a better way for
declarative transaction management instead of XML? Yes,
there is: The @Transactional annotation.
How to use Spring’s @Transactional annotation ( Declarative
Transaction Management )
Now let’s have a look at what modern Spring transaction
management usually looks like:
public class UserService {
@Transactional
public Long registerUser(User user) {
// execute some SQL that e.g.
// inserts the user into the db and retrieves the autogenerated id
// userDao.save(user);
return id;
How is this possible? There is no more XML configuration and
there’s also no other code needed. Instead, you now need to
do two things:
Make sure that your Spring Configuration is annotated
with the @EnableTransactionManagement annotation (In
Spring Boot this will be done automatically for you).
Make sure you specify a transaction manager in your
Spring Configuration (this you need to do anyway).
And then Spring is smart enough to transparently handle
transactions for you: Any bean’s public method you
annotate with the @Transactional annotation, will
execute inside a database transaction (note: there are
some pitfalls).
So, to get the @Transactional annotation working, all you need
to do is this:
@Configuration
@EnableTransactionManagement
public class MySpringConfig {
@Bean
public PlatformTransactionManager txManager() {
return yourTxManager; // more on that later
Now, when I say Spring transparently handles transactions for
you. What does that really mean?
Armed with the knowledge from the JDBC transaction
example, the @Transactional UserService code above
translates (simplified) directly to this:
public class UserService {
public Long registerUser(User user) {
Connection connection = dataSource.getConnection(); // (1)
try (connection) {
connection.setAutoCommit(false); // (1)
// execute some SQL that e.g.
// inserts the user into the db and retrieves the autogenerated id
// userDao.save(user); <(2)
connection.commit(); // (1)
} catch (SQLException e) {
connection.rollback(); // (1)
1. This is all just standard opening and closing of a JDBC
connection. That’s what Spring’s transactional annotation
does for you automatically, without you having to write it
explicitly.
2. This is your own code, saving the user through a DAO or
something similar.
This example might look a bit magical, but let’s have a look at
how Spring inserts this connection code for you.
CGlib & JDK Proxies - @Transactional under the covers
Spring cannot really rewrite your Java class, like I did above,
to insert the connection code (unless you are using advanced
techniques like bytecode weaving, but we are ignoring that for
now).
Your registerUser() method really just calls
userDao.save(user), there’s no way to change that on the fly.
But Spring has an advantage. At its core, it is an IoC container.
It instantiates a UserService for you and makes sure to
autowire that UserService into any other bean that needs a
UserService.
Now whenever you are using @Transactional on a bean, Spring
uses a tiny trick. It does not just instantiate a UserService, but
also a transactional proxy of that UserService.
It does that through a method called proxy-through-
subclassing with the help of the Cglib library. There are also
other ways to construct proxies (like Dynamic JDK proxies),
but let’s leave it at that for the moment.
Let’s see proxies in action in this picture:
As you can see from that diagram, the proxy has one job.
Opening and closing database connections/transactions.
And then delegating to the real UserService, the one you
wrote.
And other beans, like your UserRestController will never
know that they are talking to a proxy, and not
the real thing.
Quick Exam
Have a look at the following source code and tell me
what type of UserService Spring automatically constructs,
assuming it is marked with @Transactional or has a
@Transactional method.
@Configuration
@EnableTransactionManagement
public static class MyAppConfig {
@Bean
public UserService userService() { // (1)
return new UserService();
1. Correct. Spring constructs a dynamic CGLib proxy of your
UserService class here that can open and close database
transactions for you. You or any other beans won’t even
notice that it is not your UserService, but a proxy
wrapping your UserService.
For what do you need a Transaction Manager (like
PlatformTransactionManager)?
Now there’s only one crucial piece of information missing,
even though we have mentioned it a couple of times already.
Your UserService gets proxied on the fly, and the proxy
manages transactions for you. But it is not the proxy itself
handling all this transactional state (open, commit, close), the
proxy delegates that work to a transaction manager.
Spring offers you a PlatformTransactionManager /
TransactionManager interface, which, by default, comes with a
couple of handy implementations. One of them is the
datasource transaction manager.
It does exactly what you did so far to manage transactions,
but first, let’s look at the needed Spring configuration:
@Bean
public DataSource dataSource() {
return new MysqlDataSource(); // (1)
}
@Bean
public PlatformTransactionManager txManager() {
return new DataSourceTransactionManager(dataSource()); // (2)
1. You create a database-specific or connection-pool
specific datasource here. MySQL is being used for this
example.
2. Here, you create your transaction manager, which needs
a data source to be able to manage transactions.
Simple as. All transaction managers then have methods like
"doBegin" (for starting a transaction) or "doCommit", which
look like this - taken straight from Spring’s source code and
simplified a bit:
public class DataSourceTransactionManager implements PlatformTransactionManager {
@Override
protected void doBegin(Object transaction, TransactionDefinition definition) {
Connection newCon = obtainDataSource().getConnection();
// ...
con.setAutoCommit(false);
// yes, that's it!
@Override
protected void doCommit(DefaultTransactionStatus status) {
// ...
Connection connection =
status.getTransaction().getConnectionHolder().getConnection();
try {
con.commit();
} catch (SQLException ex) {
throw new TransactionSystemException("Could not commit JDBC transaction",
ex);
So, the datasource transaction manager uses exactly the
same code that you saw in the JDBC section, when managing
transactions.
With this in mind, let’s extend our picture from above:
To sum things up:
1. If Spring detects the @Transactional annotation on a
bean, it creates a dynamic proxy of that bean.
2. The proxy has access to a transaction manager and will
ask it to open and close transactions / connections.
3. The transaction manager itself will simply do what you
did in the plain Java section: Manage a good, old JDBC
connection.
What is the difference between physical and logical
transactions?
Imagine the following two transactional classes.
@Service
public class UserService {
@Autowired
private InvoiceService invoiceService;
@Transactional
public void invoice() {
invoiceService.createPdf();
// send invoice as email, etc.
@Service
public class InvoiceService {
@Transactional
public void createPdf() {
// ...
UserService has a transactional invoice() method. Which calls
another transactional method, createPdf() on the
InvoiceService.
Now in terms of database transactions, this should really just
be one database transaction. (Remember: getConnection().
setAutocommit(false). commit().) Spring calls this physical
transaction, even though this might sound a bit confusing at
first.
From Spring’s side however, there’s two logical
transactions happening: First in UserService, the other one in
InvoiceService. Spring has to be smart enough to know that
both @Transactional methods, should use the
same underlying, physical database transaction.
How would things be different, with the following change to
InvoiceService?
@Service
public class InvoiceService {
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void createPdf() {
// ...
Changing the propagation mode to requires_new is telling
Spring that createPDF() needs to execute in its own
transaction, independent of any other, already existing
transaction. Thinking back to the plain Java section of this
guide, did you see a way to "split" a transaction in half?
Neither did I.
Which basically means your code will open two (physical)
connections/transactions to the database.
(Again: getConnection() x2. setAutocommit(false) x2.
commit() x2) Spring now has to be smart enough that the two
logical transactional pieces (invoice()/createPdf()) now also
map to two different, physical database transactions.
So, to sum things up:
Physical Transactions: Are your actual JDBC
transactions.
Logical Transactions: Are the (potentially nested)
@Transactional-annotated (Spring) methods.
This leads us to covering propagation modes in more detail.
What are @Transactional Propagation Levels used for?
When looking at the Spring source code, you’ll find a variety of
propagation levels or modes that you can plug into the
@Transactional method.
@Transactional(propagation = Propagation.REQUIRED)
// or
@Transactional(propagation = Propagation.REQUIRES_NEW)
// etc
The full list:
REQUIRED
SUPPORTS
MANDATORY
REQUIRES_NEW
NOT_SUPPORTED
NEVER
NESTED
Exercise:
In the plain Java section, I showed you everything that JDBC
can do when it comes to transactions. Take a minute to think
about what every single Spring propagation mode at the
end REALLY does to your datasource or rather, your JDBC
connection.
Then have a look at the following answers.
Answers:
Required (default): My method needs a transaction, either
open one for me or use an existing one → getConnection().
setAutocommit(false). commit().
Supports: I don’t really care if a transaction is open or not,
i can work either way → nothing to do with JDBC
Mandatory: I’m not going to open up a transaction myself,
but I’m going to cry if no one else opened one up → nothing
to do with JDBC
Require_new: I want my completely own transaction
→ getConnection(). setAutocommit(false). commit().
Not_Supported: I really don’t like transactions, I will even
try and suspend a current, running transaction → nothing to
do with JDBC
Never: I’m going to cry if someone else started up a
transaction → nothing to do with JDBC
Nested: It sounds so complicated, but we are just talking
savepoints! → connection.setSavepoint()
As you can see, most propagation modes really have nothing
to do with the database or JDBC, but more with how you
structure your program with Spring and how/when/where
Spring expects transactions to be there.
Look at this example:
public class UserService {
@Transactional(propagation = Propagation.MANDATORY)
public void myMethod() {
// execute some sql
}
In this case, Spring will expect a transaction to be open,
whenever you call myMethod() of the UserService class.
It does not open one itself, instead, if you call that method
without a pre-existing transaction, Spring will throw an
exception. Keep this in mind as additional points for "logical
transaction handling".
What are @Transactional Isolation Levels used for?
This is almost a trick question at this point, but what happens
when you configure the @Transactional annotation like so?
@Transactional(isolation = Isolation.REPEATABLE_READ)
Yes, it does simply lead to this:
connection.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
Database isolation levels are, however, a complex topic, and
you should take some time to fully grasp them. A good start is
the official Postgres Documentation and their section
on isolation levels.
Also note, that when it comes to switching isolation
levels during a transaction, you must make sure to consult
with your JDBC driver/database to understand which scenarios
are supported and which not.
The most common @Transactional pitfall
There is one pitfall that Spring beginners usually run into. Have
a look at the following code:
@Service
public class UserService {
@Transactional
public void invoice() {
createPdf();
// send invoice as email, etc.
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void createPdf() {
// ...
You have a UserService class with a transactional invoice
method. Which calls createPDF(), which is also transactional.
How many physical transactions would you expect to be open,
once someone calls invoice()?
Nope, the answer is not two, but one. Why?
Let’s go back to the proxies' section of this guide. Spring
creates that transactional UserService proxy for you, but once
you are inside the UserService class and call other inner
methods, there is no more proxy involved. This means, no new
transaction for you.
Let’s have a look at it with a picture:
There’s some tricks (like self-injection), which you can use to
get around this limitation. But the main takeaway is: always
keep the proxy transaction boundaries in mind.
How to use @Transactional with Spring Boot or Spring MVC
So far, we have only talked about plain, core Spring. But what
about Spring Boot? Or Spring Web MVC? Do they handle
transactions any differently?
The short answer is: No.
With either frameworks (or rather: all frameworks in the
Spring ecosystem), you will always use the @Transactional
annotation, combined with a transaction manager and the
@EnableTransactionManagement annotation. There is no other
way.
The only difference with Spring Boot is, however, that it
automatically sets the @EnableTransactionManagement
annotation and creates a PlatformTransactionManager for you
- with its JDBC auto-configurations. Learn more about auto-
configurations here.
Recommended: Practice Spring Transactions
You can find a ton of code examples and exercises on Spring
transactions in the Spring transactions chapter of this Java
database e-book.
How Spring handles rollbacks (and default rollback policies)
The section on Spring rollbacks will be handled in the next
revision of this guide.
How Spring and JPA / Hibernate Transaction
Management works
The goal: Syncing Spring’s @Transactional and Hibernate / JPA
At some point, you will want your Spring application to
integrate with another database library, such as Hibernate (a
popular JPA-implementation) or Jooq etc.
Let’s take plain Hibernate as an example (note: it does not
matter if you are using Hibernate directly,or Hibernate via
JPA).
Rewriting the UserService from before to Hibernate would look
like this:
public class UserService {
@Autowired
private SessionFactory sessionFactory; // (1)
public void registerUser(User user) {
Session session = sessionFactory.openSession(); // (2)
// lets open up a transaction. remember setAutocommit(false)!
session.beginTransaction();
// save == insert our objects
session.save(user);
// and commit it
session.getTransaction().commit();
// close the session == our jdbc connection
session.close();
}
}
1. This is a plain, old Hibernate SessionFactory, the entry-
point for all Hibernate queries.
2. Manually managing sessions (read: database connections)
and transactions with Hibernate’s API.
There is one huge problem with the above code, however:
Hibernate would not know about Spring’s @Transactional
annotation.
Spring’s @Transactional would not know anything about
Hibernate’s transaction.
But we’d actually love for Spring and Hibernate to integrate
seamlessly, meaning that they know about each others'
transactions.
In plain code:
@Service
public class UserService {
@Autowired
private SessionFactory sessionFactory; // (1)
@Transactional
public void registerUser(User user) {
sessionFactory.getCurrentSession().save(user); // (2)
1. The same SessionFactory as before
2. But no more manual state management. Instead,
getCurrentSession() and @Transactional are in sync.
How to get there?
Using the HibernateTransactionManager
There is a very simple fix for this integration problem:
Instead of using a DataSourcePlatformTransactionManager in
your Spring configuration, you will be using
a HibernateTransactionManager (if using plain Hibernate)
or JpaTransactionManager (if using Hibernate through JPA).
The specialized HibernateTransactionManager will make sure
to:
1. Manage transactions through Hibernate, i.e. the
SessionFactory.
2. Be smart enough to allow Spring to use that very same
transaction in non-Hibernate, i.e. @Transactional Spring
code.
As always, a picture might be simpler to understand (though
note, the flow between the proxy and real service is only
conceptually right and oversimplified).
That is, in a nutshell, how you integrate Spring and Hibernate.
For other integrations or a more in-depth understanding, it
helps to have a quick look at all
possible PlatformTransactionManager implementations that
Spring offers.
Fin
By now, you should have a pretty good overview of how
transaction management works with the Spring framework and
how it also applies to other Spring libraries like Spring Boot or
Spring WebMVC. The biggest takeaway should be, that it does
not matter which framework you are using in the end, it is all
about the JDBC basics.
Get them right (Remember: getConnection().
setAutocommit(false). commit().) and you will have a much
easier understanding of what happens later on in your
complex, enterprise application.
Thanks for reading.