Question

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 a pool- 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 the http-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.

Answer 1

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 the service.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.