In order to be able to use transactions with our thread we need to understand how transactions work with spring. Transaction information in spring is stored in ThreadLocal variables. Therefore these variables are specific for an ongoing transaction on a single thread.
When it comes to an action run by a single thread the transaction gets propagated among the spring components called hierarchically.
Thus in case of a @Transactional annotated service which spawns a thread, the transaction will not be propagated from the @Transactional service to the newly created thread. The result will be an error indicating that the transaction is missing.
Since the action that take place inside your thread, requires database access through jpa, a new transaction has to be created. By looking at the @Transactional documentation we can get more information on the transaction propagation types. The default propagation mode for @Transactional is REQUIRED.
Therefore by annotating a method with the @Transactional, a new transaction will be created and will be propagated to the other services called from our thread.
For example our async method can be annotated as Transactional
@Async
@Transactional
public void executeTransactionally() {
System.out.println("Execute a transaction from the new thread");
}The same applies for the method which will be invoked from the run function of a Runnable class. Although async is pretty simple to use, behind the scenes it wraps the call in a Runnable, which dispatched to an executor.
To sum up when it comes to work with threads and transaction in spring, it should be done with extra care. Also keep in mind that the transactions cannot be passed from thread to thread. Last but not least make sure that your @Async and @Transactional functions are public and go though the proxy that will make the necessary actions before being invoked.
| Published on Java Code Geeks with permission by Emmanouil Gkatziouras, partner at our JCG program. See the original article here: Spring and Threads: Transactions Opinions expressed by Java Code Geeks contributors are their own. |
