0

From a method callAndUpdateInB(), Suppose I am calling update() method of class B(@Component), in which I am calling an myRepository.save() method to update some data in db, and in same funtion I am performing some other calls ... and then return the response back to class A.

So the problem is data gets updated in db when class B method update() return the response back to class A method callAndUpdateInB(). But it should have updated it when I have called myRepository.save() in update method of class B().

Why so ?

For Reference, just see this dummy example

class A{

    @Autowired
    B b;

    public void callAndUpdateInB(String arg){

        String data = b.update(arg);

        //    check Updates in Db (True)
        //    Now data is updated in db
    }
}  

@Component
class B{

    @Transactional(
    propagation = Propagation.REQUIRED
    )
    public String update(String arg){
        MyRepository myRepository; //  This is abstract class having 
                                   //  imlementation for the following 
                                   //  data. (MyRepositoryImpl)
        String updatedData = myRepository.save(arg);

        //    check Updates in Db (False)
        //    Making some other calls, which need that updated data
        //    But data is not still updated in db.
        //    Though here the updated data field is showing that the data is updated, but it 
        //    is not actually updated in the db.

        return updatedData;
    }
}  
MT0
  • 143,790
  • 11
  • 59
  • 117
Nakul Goyal
  • 593
  • 4
  • 12

2 Answers2

2

The transaction will be commited to the database if the method update finishes successfully.

Therefore you can't see the data before the method returns.

Additionally save does not execute the insert/update statement. This will also happen before transaction commit.

If you want to execute the statements before you have to call saveAndFlush(). BUT will also not commit the transaction and from another transaction you will not see this data as well.

This is the usual and expected transactional behavior in a Spring application using transactions.

Simon Martinelli
  • 34,053
  • 5
  • 48
  • 82
1

Propagation REQUIRED

  • Support a current transaction, create a new one if none exists. Analogous to EJB transaction attribute of the same name.

and keeps the transaction uncommitted and alive at the end of the annotated method.

If you call your update() twice at the very beginning of the request processing, the first starts a transaction and the second reuses it. If you call your update() twice, one successfully, the other unsuccessfully (on unique constraints or something), both of the changes will be rolled back.

Developers usually expect a transaction to start and end like that. But in some cases, a change needs to be committed/rolled back independently from other changes. If it is your case, you can use Propagation.REQUIRES_NEW: See https://stackoverflow.com/a/24341843/12656244

shoek
  • 380
  • 2
  • 9