How does default @Transactional work in the low level?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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
java spring spring-data-jpa spring-transactions jta
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
add a comment |
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
java spring spring-data-jpa spring-transactions jta
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
Possible duplicate of stackoverflow.com/questions/1614139/…
– Miller Cy Chan
Nov 22 '18 at 2:24
add a comment |
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
java spring spring-data-jpa spring-transactions jta
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
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
java spring spring-data-jpa spring-transactions jta
java spring spring-data-jpa spring-transactions jta
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
asked Nov 22 '18 at 0:34
WhimusicalWhimusical
2,64233877
2,64233877
Possible duplicate of stackoverflow.com/questions/1614139/…
– Miller Cy Chan
Nov 22 '18 at 2:24
add a comment |
Possible duplicate of stackoverflow.com/questions/1614139/…
– Miller Cy Chan
Nov 22 '18 at 2:24
Possible duplicate of stackoverflow.com/questions/1614139/…
– Miller Cy Chan
Nov 22 '18 at 2:24
Possible duplicate of stackoverflow.com/questions/1614139/…
– Miller Cy Chan
Nov 22 '18 at 2:24
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
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 0: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).
– Adrian M. Paredes
Nov 22 '18 at 1: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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422349%2fhow-does-default-transactional-work-in-the-low-level%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
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 0: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).
– Adrian M. Paredes
Nov 22 '18 at 1: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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
add a comment |
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.
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
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 0: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).
– Adrian M. Paredes
Nov 22 '18 at 1: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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
add a comment |
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.
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
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.
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
answered Nov 22 '18 at 0:49
Adrian M. ParedesAdrian M. Paredes
656
656
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 0: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).
– Adrian M. Paredes
Nov 22 '18 at 1: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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
add a comment |
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 0: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).
– Adrian M. Paredes
Nov 22 '18 at 1: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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
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 0:56
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 0:56
1
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).
– Adrian M. Paredes
Nov 22 '18 at 1:06
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).
– Adrian M. Paredes
Nov 22 '18 at 1:06
1
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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
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.
– Adrian M. Paredes
Nov 22 '18 at 1:18
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422349%2fhow-does-default-transactional-work-in-the-low-level%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Possible duplicate of stackoverflow.com/questions/1614139/…
– Miller Cy Chan
Nov 22 '18 at 2:24