transaction isolation level in #Transactional - quarkus

In Quarkus, is there a way to configure transaction isolation level when using #Transactional?
I'm aware that I can configure it per session, but I would like a per transaction configuration just like in Spring (see https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Transactional.html)

Quarkus doesn't handle this for now so I changed the transaction isolation level manually:
Panache.getEntityManager().createNativeQuery("set transaction isolation level serializable read write").executeUpdate();

Related

How can I replicate the rollback from Entity Manager with JPA Repository?

I am converting a project from Spring framework to Spring boot, so I am no longer using persistence files and other config files.
Also, I gave up using Entity Manager, instead I created repositories which extend JPA Repository, so that I can use the functions from there. The only thing is that I have some unit tests and in the Spring framework, at the end of each test there is a finally clause which has a rollback, so that the data from the database to be specific to each test.
How can I do that without Entity Manager? I tried using the flush() method, but no result...
By default, data JPA tests are transactional and roll back at the end of each test.
You can refer to Enabling and Disabling Transactions in spring test documentation which indicate :
Annotating a test method with #Transactional causes the test to be run within a transaction that is, by default, automatically rolled back after completion of the test. If a test class is annotated with #Transactional, each test method within that class hierarchy runs within a transaction. Test methods that are not annotated with #Transactional (at the class or method level) are not run within a transaction. Furthermore, tests that are annotated with #Transactional but have the propagation type set to NOT_SUPPORTED are not run within a transaction.
Tips :
If you want to commit the transaction for a reason or another, you can use the #Commit annotation or less properly #Rollback(false) on method or class level.
If you want to execute code outside of a transaction ( before or after ) you can use #BeforeTransaction and #AfterTransaction on public methods that have no return ( return void ) or on default method of interfaces.

How to rollback unit test while service layer is #Transactional

I am using Spring Boot 1.5.2.RELEASE and my service classes is annotated with
#Service
#Transactional(rollbackFor = Exception.class)
My unit test class is annotated with:
#RunWith(SpringRunner.class)
#SpringBootTest
I wish to roll back changes made in the database by unit test methods after test is finished.
One of the proposed solutions is to add #Transactional annotation over the test class, I tried it but this solution produces some issues, is that sometimes the test transaction is rolled back (even without no exceptions thrown!) before the service transaction is completed.
Is there another good solution to rollback test?
The solution with the #Transactional on the test class is the standard way of doing this. There is no way Spring Tx would roll back a transaction out of the blue, so I'd recommend looking closer into the issues that you encountered instead of inventing other solutions.
all changes will be rollbacked if didn't change default behaviour. And you don't have classes / methods with transaction propagation level = REQUIRES_NEW as it start independent transaction and can commit or rollback independently with the outer transaction
Transaction rollback and commit behavior
By default, test transactions will be automatically rolled back after
completion of the test; however, transactional commit and rollback
behavior can be configured declaratively via the #Commit and #Rollback
annotations.
#Rollback
#Rollback indicates whether the transaction for a transactional test
method should be rolled back after the test method has completed. If
true, the transaction is rolled back; otherwise, the transaction is
committed (see also #Commit). Rollback semantics for integration tests
in the Spring TestContext Framework default to true even if #Rollback
is not explicitly declared.
When declared as a class-level annotation, #Rollback defines the
default rollback semantics for all test methods within the test class
hierarchy. When declared as a method-level annotation, #Rollback
defines rollback semantics for the specific test method, potentially
overriding class-level #Rollback or #Commit semantics.
From the docs:
By default, test transactions will be automatically rolled back after
completion of the test; however, transactional commit and rollback behavior can be configured declaratively via the #Commit and #Rollback annotations.
Your comment:
sometimes the test transaction is rolled back (even without no
exceptions thrown !) before the service transaction is completed !
doesn't make sense to me. How did you know whether the txn completed or not if it was rolled back? Exceptions don't matter for tests, as I quoted the doc above.

Spring JPA and Sharing Entity Manager across multiple WARS and #Persistence Context thread safety

I read about about Persistence Context but not able to get a clear picture about my doubts which are as follows.
1. I have a DAO class which as a #PersistenceContext(unitName="") private EntityManager entityManager and from my Service method i am starting the transaction(Spring Managed) using #Transactional(propagation = Propagation.REQUIRED). I understand here is every time this Service method is called, a Transaction will start and when it reaches to DAO class it will use the same Transaction but for every EntityManager operation it look for Active PersistenceContext and create it as required. Is this approach correct and thread safe?
So, if a new thread starts the same service method then a new Transaction and a persistence Context will be created and flushed away when the method ends?
2. I have multiple WARS which need to interact with database so I am sharing the EntityManagerFactory using Spring Shared contexts. I am having all the Hibernate related configurations at a common place and in every WAR i am specifying where transactionManager will be shared. Is it right?
Please clarify my doubts and your comments are valued. Thanks in advance.

No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here

I have problem with:
No Hibernate Session bound to thread, and configuration does not allow
creation of non-transactional one here
when testing my project.
I use Spring 2.0.7(this is must in that project) and Hibernate 3. I have
SessionFactory defined
Transaction manager defined(with session factory injected)
<tx:annotation-driven transaction-manager="transactionManager"/> -
annotations for transactions switched on
I have annotated my tests with:
#Test
#Transactional
and inherited AbstractAnnotationAwareTransactionalTests
=> I got this error:No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
Only way I can overcome it is to use: TransactionStatus transaction = transactionManager.getTransaction(transactionDefinition);
in test before I call
sessionFactory.getCurrentSession().save(myObject);
Any suggestions? Or better: how it works? Why it can not create transactional session ? Why no hibernate session is bound ? I have read something about it but it is still not clear to me. I think that I did everything to make it working but obviously it was not sufficient.
Thx in advance,
Stepik
I think the problem consist in that you extend your class from AbstractAnnotationAwareTransactionalTests. Try to remove inheritance (it should work without it). Or try to extend your class from AbstractTransactionalJUnit4SpringContextTests class.
You can look here at similar post.
In my case a base-package was missed. One like:
<context:component-scan base-package="com.companyname" />

What's the difference between using #Transactional and Spring template?

If I use #Transactional in my DAO will all of my EntityManager queries be encapsulated with commit and close? Or do I need to use Spring template (JPA template, Hibernate template)? What's the difference between using #Transactional and Spring template?
The difference between using annotation-based transaction demarcation (#Transactional) and the TransactionTemplate is that TransactionTemplate couples you to Spring's transaction infrastructure and means that you will programmatically handle setting the transaction status if the transaction should be rolled back. You can use annotation-based transaction demarcation with the Spring transaction support or with AspectJ transactions outside of a Spring container.
See also the online documentation for transactions in Spring.
The Spring template classes are only there to provide a nicer API for doing persistence operations - they do not deal with transactions. If you want to have transactional operations, you either need to use the #Transactional annotation approach, or use TransactionTemplate.
When you use #transactional with the proper Spring configuration, Spring will recognize that the method needs an transaction and will handle the transaction creation, commit and close for you.
Like skaffman said, #transactional is not directly tied to the template classes. They can be used for any class that may need transactions.
do u mean usin #transactional will encapsulate my dao methods with commit,close or when using spring transaction template (jpatemplate, hibernatetemplate) ?

Resources