Spring Boot 2.7迁移至3.3（Open Liberty）遇@Transactional只读事务异常问题

背景 #

我们正将Spring Boot应用从2.7版本迁移至3.3版本，搭配最新版Open Liberty服务器与Oracle 19数据库。服务类上标注有@Transactional(readOnly = true)注解，升级后调用查询方法时出现如下错误：

org.springframework.transaction.UnexpectedRollbackException: JTA transaction unexpectedly rolled back (maybe due to a timeout)

经排查，该错误在服务层抛出RuntimeException类型业务异常时触发——默认情况下RuntimeException会导致事务回滚。旧系统无此问题，原因是旧系统Spring自动使用WebSphereUowTransactionManager，新系统则使用JtaTransactionManager，二者行为存在差异：WebSphereUowTransactionManager在@Transactional(readOnly = true)场景下不会触发该异常，但该类已从spring-tx 6中移除，无法在Spring Boot 3.3中配置。

目前采用的替代方案：将注解修改为@Transactional(readOnly = true, noRollbackFor = CustomApplicationException.class)，运行正常。

问题1：如何在Spring Boot 3.3中使用WebSphereUowTransactionManager？ #

• WebSphereUowTransactionManager已在Spring Framework 6.x（对应Spring Boot 3.x）的spring-tx模块中被移除，官方不再提供支持，无法直接在Spring Boot 3.3中配置使用。
• 若想沿用类似WebSphere UOW的事务逻辑，需自行基于Open Liberty的JTA API实现适配，或切换到Open Liberty原生事务管理机制，但这会增加应用与容器的耦合度，偏离Spring Boot自动配置的设计理念。

问题2：该替代方案是否可行？是否存在潜在问题？ #

可行性 #

该方案完全可行。通过noRollbackFor显式指定不触发事务回滚的自定义业务异常，避免了只读事务因预期业务异常触发回滚，进而抛出UnexpectedRollbackException的问题，当前运行状态已验证这一点。

潜在问题 #

• 事务语义不一致风险：必须确保CustomApplicationException仅用于业务层面的预期异常（如数据不存在、参数不合法等），不涉及需要回滚的错误场景。若后续该异常被误用表示数据操作失败类错误，会导致事务无法正常回滚，引发数据不一致。
• 维护成本：若后续新增其他业务异常类型，需同步更新noRollbackFor的配置，遗漏会导致同类问题复现。建议定义一个业务异常基类，将noRollbackFor指向该基类，减少重复配置。
• 只读事务合理性校验：确认查询场景使用readOnly = true的必要性，该属性主要用于提示数据库执行优化（如Oracle的只读事务快照）。若业务异常触发时不需要回滚，本质是该事务无需回滚语义，需确保业务设计与事务配置逻辑自洽。

内容的提问来源于stack exchange，提问作者Mark