2

Everywhere is written that service(or whatever) method should be Transactional for JPA Persistence Context to be created, but I can't find anywhere what is the motivation of such design.

Say I want to insert one row to DB, it is just one DB statement which will be anyway transactional if autocommit is enabled. But suddenly if you use JPA/Hibernate then you have to make your business method @Transactional for JPA to be able to create a Persistence Context and execute that single statement.

In the JPA-less world we can have a non-transactional service method containing even multiple DB statements, of course, taking the risk of losing the atomicity of the whole operation(that is definitely our choice), so why JPA is designed that way forcing us to create Transactional methods even when that method contains single DB statement and anyway that statement will be executed in transaction with autocommit=true?

Suren Aznauryan
  • 984
  • 10
  • 24
  • Possible duplicate of [Application managed JPA, when is Transaction needed](https://stackoverflow.com/questions/21672454/application-managed-jpa-when-is-transaction-needed) –  Oct 28 '18 at 12:51
  • My question is not a duplicate of that one as the answer there says `Methods that specify a lock mode other than LockModeType.NONE must be invoked within a transaction context. If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.`. Any sql statement is executed in transaction if `autocommit` mode is `on`. My question is why we should opt-out of `autocommit=true` and manually set the transaction boundaries – Suren Aznauryan Oct 28 '18 at 12:57

4 Answers4

1

I believe that everything that is about a RDBMS is going to be transactional even though it is an atomic operation or a non-JPA case. Speaking of losing data everything just depends on a configured isolation level. Even if you don't use any explicit transaction configuration, e.g. by using JdbcTemlate or just java core Statement, transaction will be created implicitly.

So answering your question, JPA is forcing using transaction to make a developer understans his actions.

Possible in your case key words to get the answer are persistence state of an entity. Here is a nice article that explains how JPA works with entities.

Yuriy Tsarkov
  • 2,461
  • 2
  • 14
  • 28
0

It's not a JPA related thing. All database operations require a transaction, every single one of them. The thing is that sometimes it's just hidden from you as if you don't explicitly create a transaction, the underlying framework will do it for you (this is the case for selecting entities in JPA).

Overall, JPA is not forcing you, the database is forcing you to do it and this is the nature of the RDBMS.

Arnold Galovics
  • 3,246
  • 3
  • 22
  • 33
  • All the database statements are executed in a transaction, whether `autocommit` is `true` or `false`, that's clear. My question is that when we don't use JPA/Hibernate we can have non-transactional service methods executing several DB statements, meaning that we are not disabling `autocommit` and every statement does execute as a separate transaction, but in case of JPA/Hibernate it forces us to make the service transactional meaning that we opt out of `autocommit` and set the transaction boundaries manually – Suren Aznauryan Oct 28 '18 at 13:05
0

This question contains more than one point:

  1. JPA is implementation for ORM "Object-relational mapping" which is by definition map the objects you are using with the data on DB bi-directional and for that it have to solve meltable issues could happened so it is introducing transactions to solve such issues.
  2. (saving only one item) is not atomic operation as you could have 2 transactions saving different data in same field "talking about update for create or add your object not mapped until you call persist" or 2 transition have different dirty values, so globally your save operation is not
Bassem Reda Zohdy
  • 12,662
  • 3
  • 33
  • 39
  • saying `saving only one item is atomic` I was meaning that anyway it is one db statement and with `autocommit` enabled anyway it will be in transaction, why I need to set the transaction boundaries manually? – Suren Aznauryan Oct 28 '18 at 13:11
0

It is not related to JPA. It is related to the TransactionManager you probably configured to work. A JTA-Transactionmanager together with the EntityManager-Object will handle the database connections and make sure that you do no DB-Changes without having started a transaction.

The JPA-Entitymanager itself contains methods you can use to handle transactions.

In the EntityManager-javadoc you see:

TransactionRequiredException - if there is no transaction when invoked on a container-managed entity manager of that is of type PersistenceContextType.TRANSACTION

So you see as soon as you use a TransactionManager, the entitymanager gets container managed.

Also see: Container Managed Entitymanager

aschoerk
  • 3,333
  • 2
  • 15
  • 29