How to Upgrade Spring Boot for MongoDB Transaction Support
This guide explains why upgrading from Spring Boot 1.5 to 2.1 is essential for MongoDB transaction management, outlines version requirements, highlights key feature changes, and provides step‑by‑step instructions with code examples to enable reliable transactional operations in a Spring‑based backend.
Background
The company currently uses Spring Boot 1.5.12.RELEASE, which does not support MongoDB transaction management. As business complexity grows, ensuring data consistency and atomicity becomes critical.
Why Upgrade Spring Boot
Data consistency: Newer Spring Boot versions support MongoDB transactions, guaranteeing atomic operations and improving system stability.
Technical alignment: Keeping the stack up‑to‑date ensures compatibility with other components and provides performance improvements.
Developer efficiency: Simplified transaction handling reduces code complexity, boosts development speed, and lowers maintenance costs.
Version Selection
Requirements for MongoDB transaction support:
Mongodb 4.0 replica set or 4.2 sharded cluster (required)
spring.data.mongodb version 2.1+ (required)
Spring Boot version 2.1+ (required)
Since the project already uses MongoDB 4.0+, only Spring Boot and spring.data.mongodb need upgrading.
Chosen versions:
spring.data.mongodb: 2.1.15.RELEASE
springboot: 2.1.12.RELEASE
Feature Highlights
Default Dynamic Proxy Strategy
Uses CGLIB proxies by default, including AOP. To switch to interface‑based proxies, set
spring.aop.proxy-target-class=false.
WebMvcConfigurerAdapter Deprecated
The abstract class
WebMvcConfigurerAdapteris obsolete; replace it with
WebMvcConfigurer.
<code>public class MyWebMvcConfigurerAdapter implements WebMvcConfigurer {
// ...
}</code>Relational Database
The default connection pool changes from Tomcat to HikariCP (performance: HikariCP > Druid > tomcat‑jdbc > dbcp > c3p0). Use
spring.datasource.typeto enforce Hikari.
Redis
When using
spring-boot-starter-redis, Lettuce replaces Jedis as the default driver, though Jedis remains supported and can be swapped via dependency exclusion.
Server‑Specific Properties
Several servlet‑specific settings have moved to
server.servletproperties.
Dependency Versions
Elasticsearch 5.6
Gradle 4
Hibernate 5.2
Jetty 9.4
Spring Framework 5
Spring Security 5
Tomcat 8.5
More Features
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1-Release-Notes
Upgrade Steps
Step 1 – Modify pom.xml
Update the parent version:
<code><parent>
<groupId>suishen-webx</groupId>
<artifactId>suishen-webx-parent</artifactId>
<version>2.0-SNAPSHOT</version>
</parent></code>Confirm dependency versions in the project (see screenshot).
Step 2 – Enable Transactions
Add
@EnableTransactionManagementto the main application class:
<code>@EnableTransactionManagement
public class MainApplication extends SuishenWebxApplication {
}</code>Configure a MongoDB transaction manager either via XML:
<code><!-- Configure MongoDB transaction manager -->
<bean id="transactionManager" class="org.springframework.data.mongodb.MongoTransactionManager">
<constructor-arg name="dbFactory" ref="mongoDbFactory"/>
</bean></code>or via Java configuration:
<code>@Configuration
public class TransactionConfig {
@Bean
public MongoTransactionManager transactionManager(MongoDatabaseFactory factory){
return new MongoTransactionManager(factory);
}
}</code>Step 3 – Adjust MongoDB Password
spring.data.mongodb 2.1.15.RELEASE decodes passwords with
URLDecoder.decode, so percent signs (%) must be escaped as
%25. Verify the process using
MongoCredentialPropertyEditor.extractUserNameAndPassword.
Using Transactions
Declarative Transaction Handling
Annotate methods with
@Transactional:
<code>@SuishenLog(logName = "Add Strategy")
public StrategyVo addStrategy(StrategyAddReq addReq) {
// business logic
}
@SuishenLog(logName = "Add Strategy Transaction")
@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
public StrategyVo addStrategyTest(StrategyAddReq addReq) {
return addStrategy(addReq);
}</code>Transaction Propagation Behaviors
PROPAGATION_REQUIRED – default; joins existing transaction or creates a new one.
PROPAGATION_SUPPORTS – joins if present, otherwise executes non‑transactionally.
PROPAGATION_MANDATORY – must have an existing transaction, else throws.
PROPAGATION_REQUIRES_NEW – suspends current transaction and starts a new one.
PROPAGATION_NOT_SUPPORTED – suspends any transaction and runs non‑transactionally.
PROPAGATION_NEVER – throws if a transaction exists.
PROPAGATION_NESTED – uses savepoints for nested transactions.
Programmatic Transaction Handling
<code>@SuishenLog(logName = "Add Strategy Transaction Test")
@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
public StrategyVo addStrategyTest2(StrategyAddReq addReq) {
return addStrategy(addReq);
}
TransactionTemplate txTemplate = new TransactionTemplate(mongoTransactionManager);
return txTemplate.execute(new TransactionCallback<StrategyVo>() {
@Override
public StrategyVo doInTransaction(TransactionStatus status) {
try {
return addStrategy(addReq);
} catch (Exception e) {
status.setRollbackOnly();
}
return null;
}
});</code>Data Verification
Calling
addStrategysucceeds for Strategy but fails for StrategyLog.
Calling
addStrategyTestrolls back both inserts.
Calling
addStrategyTest2also rolls back both inserts.
<code>org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(...)
...</code>Author: Sun Jingliang, Senior Backend Engineer.
WeiLi Technology Team
Practicing data-driven principles and believing technology can change the world.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.