CODEWITHSUNDEEP
javaspringasynchronousconcurrencyspring-async
Shree
Shree

Reputation: 41

Spring @Transaction and @Async usage for database operations

In a spring application when we receive message @Service persist bean is calling the database operation to insert in to database & parallel @Service to parse & process message. In this case persist is using @Transactional. In order to make the flow in parallel, is it advised to add @Async for persist.

Additionally there is @Aspect on each save method called by persist service for logging & audit.

Upvotes: 1

Views: 5387

Answers (1)

Nathan Hughes
Nathan Hughes

Reputation: 96385

All that @Async does is cause the methods of the annotated component to be executed on another thread, where it gets the thread from a pool (which can be specified, so you can choose for some operations to have a dedicated pool).

@Async itself doesn’t do anything to lock database tables, or anything else database-related. If you want database-level locking you will have to implement that through some other means. If you want the call to use a transaction you have to use the @Transactional annotation on the component being called asynchronously. The transaction will be separate from the caller's transaction. Of course the transaction can possibly cause database locking depending on the isolation level and database implementation.

It’s tricky to use @Async with database work. One pitfall occurs with jpa persistent entities passed across threads, when they have a lazy property that gets realized in the new thread (where the proxy is now invalid because it can’t get to the entityManager from the old thread). It’s safer if the things passed between threads are immutable.

@Async adds complexity and is hard to reason about. There are opportunities for race conditions and deadlocks where if you don’t get it exactly right then bad things can happen, and you can’t count on testing to uncover the issues. It’s working without a net, if you want any infrastructure to help with exception handling, retries, or other recovery you will have to provide it yourself.

So no, I wouldn’t necessarily call it advisable. It's a good capability to have in your toolbox that might be helpful for a few isolated cases, but pervasive usage would seem like a bad thing. There are alternatives if you’re looking for ways to persist data without blocking.

Upvotes: 3

Related Questions