Spring声明式事务和手动调度线程
我有一个奇怪的问题。
在我的一个类中:
private final ScheduledExecutorService executor
= Executors.newSingleThreadScheduledExecutor();
public MyClass(final MyService service) {
executor.scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
service.foo();
}
}, 0, 30, TimeUnit.SECONDS);
}
MyService
是一个 spring bean,其 foo
方法上有 @Transactional
。 MyClass
仅实例化一次(在应用程序中有效地单例)
在第一次调用 service.foo()
(工作正常)之后,在对应用程序的后续请求中,我随机得到:
java.lang.IllegalStateException:已经值[SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=[]更新=[]删除=[]collectionCreations=[]collectionRemovals=[]collectionUpdates =[]])] 绑定到线程的键 [org.hibernate.impl.SessionFactoryImpl@2cd91000] [http-bio-8080-exec-10]
一些观察结果:
- 当抛出异常时,存储在
TransactionSynchronizationManager
中的会话被关闭 - 手动调度线程的事务同步管理器资源映射为
- 空异常发生在
http-bio-8080-exec
线程中,但手动调度的线程是pool-
线程 - 因此不存在“线程污染” MyClass< /code> 已实例化启动时,在名为“Thread-5”的线程中,即它与
http-bio
线程没有任何关系。
如果我注释对 service.foo()
的调用,或者去掉 @Transactioanl
注释,一切都会正常(当然,除了数据未插入到db)
有什么线索可能是什么问题吗?
(注意:我不想使用 @Scheduled - 我不希望 MyClass 成为 spring bean,并且可运行对象必须先对其某些内部状态进行操作调用服务)
更新:一段时间后,即使没有调度的东西,我也能够重现它。所以我正在使用的最新快照可能是一个普遍的弹簧问题。
I'm having a strange issue.
In a class I have:
private final ScheduledExecutorService executor
= Executors.newSingleThreadScheduledExecutor();
public MyClass(final MyService service) {
executor.scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
service.foo();
}
}, 0, 30, TimeUnit.SECONDS);
}
MyService
is a spring bean that has @Transactional
on its foo
method. MyClass
is instantiated only once (effectively singleton in the application)
After the first invocation of service.foo()
(which works fine), on subsequent requests to the application I am randomly getting:
java.lang.IllegalStateException: Already value [SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=[] updates=[] deletions=[] collectionCreations=[] collectionRemovals=[] collectionUpdates=[]])] for key [org.hibernate.impl.SessionFactoryImpl@2cd91000] bound to thread [http-bio-8080-exec-10]
A few observations:
- when the exception is thrown, the session stored in the
TransactionSynchronizationManager
is closed - the transaction synchronization manager resource map for the manually scheduled thread is empty
- the exception occurs in
http-bio-8080-exec
threads, but the manually scheduled one is apool-
thread - so there is no 'thread polution' MyClass
is instantiated on startup, in a thread named "Thread-5", i.e. it is not in any way related to thehttp-bio
threads.
If I comment the invocation to service.foo()
, or get rid of the @Transactioanl
annotation, everything works (except, of course, that data is not inserted in the db)
Any clues what the issue might be?
(Note: I prefer not to use @Scheduled
- I don't want MyClass
to be a spring bean, and the runnable has to operate on some of its internal state before invoking the service)
Update: After a while I'm able to reproduce it even without the scheduling stuff. So probably a general spring problem with the latest snapshot I'm using.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我假设异常来自 TransactionInterceptor 或类似的东西(一些 Spring 基础设施 bean),或者您是否在自己的代码中使用
TransactionSynchronizationManager
?在我看来,某些东西正在将会话绑定到容器管理的线程(是 Tomcat 7?),并且在它们返回到容器的线程池之前无法取消绑定它们。因此,当稍后将同一线程用于另一个事务请求时,Spring 无法将新会话绑定到它,因为旧会话没有被清理。我实际上没有看到任何东西让我认为它与您使用
MyClass
的自定义调度直接相关。您确定删除service.foo()
调用时没有看到异常不仅仅是巧合吗?如果您可以在调试器中捕获其中一个线程,当它返回到池中且会话仍与其绑定时,您也许能够回溯到它的用途。理论上,全知调试器非常适合此目的,尽管我自己从未使用过: ODB 和 < a href="http://pleiad.cl/tod/" rel="nofollow">TOD 是我所知道的两个。
编辑:查找违规线程的更简单方法:向您的应用程序添加一个过滤器(即 servlet 过滤器),该应用程序“围绕”其他所有内容运行。在 chain.doFilter() 之后,作为处理请求离开应用程序之前的最后一个操作,请检查 TransactionSynchronizationManager.getResourceMap()。当您处理完请求后,它应该是一个空地图。当您发现不存在的情况时,您需要从那里回溯以查看发生了什么。
I assume that exception comes from an invocation of the TransactionInterceptor or the like (some Spring infrastructure bean), or are you using the
TransactionSynchronizationManager
from your own code somewhere? It appears to me that something is binding sessions to a thread being managed by your container (is that Tomcat 7?) and failing to unbind them before they're returned to the container's thread pool. Thus when the same thread is used for another transactional request later, Spring can't bind the new Session to it because the old one wasn't cleaned up.I don't actually see anything to make me think it's directly related to your custom scheduling with
MyClass
. Are you sure it's not just a coincidence that you didn't see the exception when you remove theservice.foo()
call?If you could catch one of those threads in a debugger when it's being returned to the pool with a Session still bound to it, you might be able to backtrack to what it was used for. An omniscient debugger would theoretically be perfect for this, though I've never used one myself: ODB and TOD are the two I know of.
Edit: An easier way to find the offending threads: add a Filter (servlet filter, that is) to your app that runs "around" everything else. After chain.doFilter(), as the last act of handling a request before it leaves your application, check the value of TransactionSynchronizationManager.getResourceMap(). It should be an empty map when you're done handling a request. When you find one that isn't, that's where you need to backtrack from to see what happened.