Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Transaction timeouts when Vaadin UI is idle for more than 5 mins
I am seeing the below exception whenever the Vaadin UI is idle for more than 5 minutes when a background process runs due to some action(for ex: File download or any business logic).
The application is deployed on tomcat and below are some of the settings,
The session timeout defined in web.xml is 60 mins.
The jta properties has below max_timeout
com.atomikos.icatch.max_timeout = 3600000
The heartbeatInterval is set to as below
java.lang.IllegalStateException: This method needs a transaction for the calling thread and none exists.
Possible causes: either you didn't start a transaction,
it rolledback due to timeout, or it was committed already.
ACTIONS: You can try one of the following:
1. Make sure you started a transaction for the thread.
2. Make sure you didn't terminate it yet.
3. Increase the transaction timeout to avoid automatic rollback of long transactions;
check http://www.atomikos.com/Documentation/JtaProperties for how to do this.
Any help on how to resolve this is appreciated.
This doesn't seem to be a Vaadin issue, as it is your background thread that throws the exception. I see you are using JTA; probably your background thread expects a user to be logged in and have an active transaction, which obviously isn't what happens. What is your tech stack, and how do you create the background thread?
Thanks for the response.
The technology stack is Tomcat, Vaadin, Proprietary bean framework(like Hibernate).
The new thread still remains active after the exception is thrown and while debugging it can be seen that the control reaches the debug point placed in the business logic associated with the new thread whereas the application is routed to login page.
The thread creation logic is as below,
Thread t = new Thread(instance of class that implements Runnable interface and contains business logic);
Any further suggestions to resolve the issue are highly appreciated.
I'm not that familiar with JTA, but what I guess is going on is that you need to associate the newly created thread with the existing transaction. So calling getTransaction() on the original thread and then resume() on the newly created thread.