启动时JMS监听器无法获取UserTransaction，前端访问后恢复正常

核心原因：JMS监听器启动时机与事务上下文初始化不匹配 #

你的问题本质是JMS监听器在Spring容器未完成事务组件全量初始化时就开始工作，导致Hibernate无法获取到JTA事务所需的UserTransaction，具体拆解：

1. 启动时报错的原因 #

虽然数据源配置先加载，但：

• 你用的JTA事务管理器（或Hibernate整合JTA的配置）中，UserTransaction可能是延迟初始化的（比如默认lazy-init="true"），或者JMS监听器的MessageListenerContainer在容器启动阶段就提前启动监听。
• JMS监听器的线程在启动时，UserTransaction还未被注册到JNDI上下文或线程绑定，Hibernate开启事务时自然找不到它，抛出JndiException。

2. 前端访问后恢复正常的原因 #

前端请求触发了Spring MVC的请求处理流程，这个过程会强制初始化所有与请求、事务相关的Bean：

• 比如DispatcherServlet初始化时会触发SessionFactory、TransactionManager的完整初始化，把UserTransaction注册到JNDI；
• 第一个请求的线程会绑定事务上下文，后续JMS监听器的线程就能正常获取到UserTransaction了。

3. 复制SessionFactory到JMS配置解决问题的原因 #

这相当于给JMS监听器的配置添加了显式依赖：

• Spring容器会严格保证sessionFactory（以及它依赖的TransactionManager、UserTransaction）在JMS监听器的MessageListenerContainer之前完成初始化，避免了监听器“抢跑”的情况。
• 之前的配置里，JMS组件没有显式依赖sessionFactory，哪怕数据源配置先加载，容器也无法保证事务组件的初始化顺序，导致监听器启动时事务上下文未就绪。

更优雅的解决方案 #

不建议复制Bean（会导致Bean重复定义，埋下隐患），可以用以下方式解决：

• 给JMS的MessageListenerContainer添加depends-on="sessionFactory"属性，强制它在sessionFactory初始化完成后再启动。
• 检查事务管理器（比如JtaTransactionManager）的配置，设置lazy-init="false"，确保UserTransaction在容器启动时就完成初始化。
• 如果允许延迟启动监听器，可以把MessageListenerContainer的autoStartup设为false，然后通过ApplicationListener监听ContextRefreshedEvent事件，在容器完全初始化后手动启动监听器。

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