When I try to read data from the database, at least using
((Session)em.getDelegate()).createCriteria()
an exception is throws saying that a transaction is not present.
When I add the annotation:
@Transactional(
value = SomeClass.TRANSACTIONAL_MANAGER,
propagation = Propagation.SUPPORTS,
readOnly = true
)
it works fine.
However, since reading will happen million of times per second to access and read data, I want to make sure that our environment is not clogged up unnecessarily.
If not, what is the cost of creating a read-only Propagation.Supports transaction?
Can I not create a Hibernate Criteria Query without a transaction, in combination with Spring?
Advertisement
Answer
All database statements are executed within the context of a physical transaction, even when we don’t explicitly declare transaction boundaries (BEGIN/COMMIT/ROLLBACK).
If you don’t declare transaction boundaries, then each statement will have to be executed in a separate transaction (autocommit mode). This may even lead to opening and closing one connection per statement unless your environment can deal with connection-per-thread binding.
Declaring a service as @Transactional will give you one connection for the whole transaction duration, and all statements will use that single isolation connection. This is way better than not using explicit transactions in the first place.
On large applications, you may have many concurrent requests, and reducing database connection acquisition request rate will definitely improve your overall application performance.
JPA doesn’t enforce transactions on read operations. Only writes end up throwing a TransactionRequiredException in case you forget to start a transactional context. Nevertheless, it’s always better to declare transaction boundaries even for read-only transactions (in Spring @Transactional allows you to mark read-only transactions, which has a great performance benefit).
Now, if you use declarative transaction boundaries (e.g. @Transactional), you need to make sure that the database connection acquisition is delayed until there is a JDBC statement to be executed. In JTA, this is the default behavior. When using RESOURCE_LOCAL, you need to set the hibernate.connection.provider_disables_autocommit configuration property and make sure that the underlying connection pool is set to disable the auto-commit mode.