@Transactional noRollbackFor未按预期生效，远程调用WAR后事务异常

这问题我之前在WebLogic 12的分布式应用环境里碰到过类似的，核心是跨模块远程调用时的事务上下文传播、容器异常包装以及JTA规范约束导致的，给你几个针对性的排查方向：

• 确认远程调用抛出的异常实际类型
  WebLogic的远程调用（比如EJB Remote、RMI）会自动把服务端抛出的异常包装成RemoteException或者它的子类，哪怕服务端抛的是RuntimeException。你的@Transactional(noRollbackFor=RuntimeException.class)只排除了RuntimeException类型，但如果实际捕获的是RemoteException，这个配置就不会生效，事务会被直接标记为rollback-only。建议在捕获异常的代码里打印异常的getClass().getName()和完整栈轨迹，看看实际拿到的异常到底是什么类型。

• 检查事务传播属性的配置
  默认的事务传播是REQUIRED，这意味着远程调用会加入当前的事务上下文。如果远程服务抛出异常，不管你本地有没有捕获，远程的事务管理器已经把整个全局事务标记为回滚状态了。你可以尝试把远程调用的事务传播属性改成REQUIRES_NEW，让远程调用在独立的事务里执行，这样远程的异常不会影响本地的事务上下文。注意：这个调整要结合业务逻辑，确保分布式场景下的数据一致性符合你的预期。

• 排查WebLogic JTA事务管理器的行为
  根据JTA规范，一旦事务被标记为rollback-only，就无法再恢复为可提交状态，后续所有属于该事务的数据库操作都会失败。WebLogic的事务管理器在处理远程调用异常时，可能会直接触发这个标记，哪怕你的方法配置了noRollbackFor。你可以登录WebLogic控制台，在事务监控里查看对应事务的状态，同时检查Domain的日志文件（比如server.log），搜索rollback-only或者事务ID，确认是不是远程调用触发了这个不可逆的状态。

• 验证类加载隔离导致的异常匹配问题
  WebLogic中EAR和WAR的类加载器是相互隔离的，可能出现同一个异常类在两个模块中被不同类加载器加载的情况。这时候就算远程抛出的是RuntimeException子类，本地代码里的instanceof判断会失败，导致@Transactional的noRollbackFor规则不生效。你可以在捕获异常时打印异常对象.getClass().getClassLoader()，对比EAR和WAR中该异常类的类加载器是否一致。

• 排查分布式事务的影响
  如果远程调用涉及跨JVM或者不同数据源的分布式事务，WebLogic的分布式事务管理器会遵循两阶段提交（2PC）规则。一旦分布式事务的某个分支出现异常，整个全局事务会被标记为回滚，后续的数据库操作自然会失败。你可以检查远程服务的数据源配置，确认是否和本地数据源属于同一个分布式事务域，或者是否开启了不必要的分布式事务。

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