What happens when a @Transactional annotated method is hit in parallel by multiple instances?

Question

Please correct me if I am wrong somewhere.

I am having an issue where my transaction are not being saved to the data base and some sort of racing is occurring which screws up the data. The app is hit in parallel by multiple instances. I have used @Transactional, which I know is to do a transaction with database and the transaction is committed when the method returns.

The question is, does hitting it through multiple instance still maintain this one transaction per hit thing, or it does not handle the situation and data will screw up because of racing?

Can a solution be suggested for the given condition?

Answer 1

The @Transactional is not related to synchronization. It just makes sure that your flow either succeeds or fails. Each hit has its own flow and its own success or failure.

I guess what you're experiencing is due to the use of shared data.

For example. If you have a class Foo that looks like this:

public class Foo {
    private static boolean flag = true;

    @Transactional
    public void doSomething() {
        flag = false;
    }
}

In this case it doesn't matter that you have many Foo instances because they all use the same flag.

Another scenario would be if you have one instance of Foo (very common if you use something like Spring) and you have data that is changed for this instance. You can look at the same Foo example and just remove the static from flag:

public class Foo {
    private boolean flag = true;

    @Transactional
    public void doSomething() {
        flag = false;
    }
}

In either of those cases you need to synchronize the data changes somehow. It has nothing to do with @Transactional.

Answer 2

That transactions are database transactions and behavior is database engine dependant but it usually works this way:

1. A thread enter the method.
2. A thread enter the same or any other transactional method. It does not block as @Transactional is not about synchronization.
3. One thread execute any query that blocks a database resource. Eg. SELECT * FROM MYTABLE FOR UPDATE;.
4. Another thread try to execute anything that needs the same database resource. Eg. UPDATE MYTABLE SET A = A + 1; And it blocks.
5. The thread that acquired the lock on step 3 completes the transactional method successfully making an implicit commit or fails making an implicit rollback.
6. The blocked thread wakes up and continues as it can now get the resource that was locked.