2

Does a propagation-Required default @Transactional collects all queries and executes them at the end of the method altogether or does it open a db transaction and executes BEGIN, every query as it finds it and when transaction finishes executes COMMIT?

Is this what is referred as Logical vs Physical transactions?

I am wondering that because I am using a @Transactional tests that executes GET endpoint + DELETE endpoont + GET endpoint with READ_UNCOMMITED, behavior manages to work well, but I see no trace of delete queries in the logs, only selects.

I would have expected I see all the queries issued and then a rollback, but I have the feeling that the transaction is just modifying the managed entities of the persistance context and just tries to save by the end of the test...

If I should be seeing all the delete queries as the repository.removes() are executed then it might be that for some reason hibernate is only logging queries out of a readonly=false transaction

Whimusical
  • 6,401
  • 11
  • 62
  • 105

1 Answers1

1

Maybe this answer helps you: JPA flush vs commit

If there is an active transaction, JPA/Hibernate will execute the flush method when transaction is committed. Meanwhile, all changes applied to entities are collected in the Unit of Work.

In flush() the changes to the data are reflected in database after encountering flush, but it is still in transaction.flush() MUST be enclosed in a transaction context and you don't have to do it explicitly unless needed (in rare cases), when EntityTransaction.commit() does that for you.

You can change this behavior changing the flush strategy.

  • I am no native speaker and I don't get the gramatics of the orange area :(. Do I understanding it well so all queries are executed at the end of transaction when the commit() occurs? If so, then all transaction is managed logically, what is the point of needing a db with transaction support and the like? Can spring just execute 5 queries altogether if no exception occirred during the flow? – Whimusical Nov 22 '18 at 00:56
  • 1
    When you use a transaction manager inside the Spring container or in a Java EE application server like JBoss (Wildfly) or Weblogic, you have business transactions and system transactions. Business transactions are managed by the Java container, and system transactions are managed by database underlying. It's a matter of performance. Hibernate inside a transaction optimizes database accesses. It's useful for distributed transactions too (when you have two o more databases in the same transaction). – Adrián Paredes Nov 22 '18 at 01:06
  • 1
    Besides, Hibernate is a very intelligent guy. Sometimes it groups several updates to minimize the number of queries. For example: If you update an attribute and later another attribute from the same entity. Sometimes it understands that certain updates are no longer need to be executed. For example: If you update an attribute but then you update again the same attribute to the original value. – Adrián Paredes Nov 22 '18 at 01:18