I am confused about @Transactional annotation with base and subclasses. I have the following code with several generic subclasses derived from the base class CustomRepository<T> which implements ICustomRepository<T>. I want all the methods of the interface ICustomRepository<T> be transactional. Is it enough to put @Transactional just in the base class so that the call findAll() from sublasses also become transactional.
Tag: transactions
Run code without transaction in transactional mehod spring
I have service like this: How can I run method2 without transaction or in new transaction? Can I run in my controller class this 2 method like this: Answer @Transactional is powered by Aspect-Oriented Programming. Therefore, processing occurs when a bean is called from another bean. You can resolve this problem by self-inject create another bean.
Overriding transaction propagation levels for methods having Spring’s @transactional
I have multiple methods in my codebase annotated with Spring’s @transactional with different propgation levels (lets ignore the idea behind choosing the propagation levels). Example – Now I have a new use case where I want to perform all these operations in a single transaction (for this specific use case only, without modifying existing behavior), overriding any annotated propagation levels.
Using AOP and DI itself causes Spring ApplicationListener to be fired twice
Software versions Spring Version 5.3.18 and earlier JDK Version 1.8.0_202 Overview When I use Spring ApplicationListener, in order to prevent transaction invalidation, my ApplicationListener implementation class writes the following code (of course, the code can be written differently to avoid this problem), which will cause my listener to trigger twice after the event is published. I think it’s not normal,
OpenLiberty JakartaEE 9: access TransactionManager
On Docker Image open-liberty:22.0.0.1-full-java17-openj9 with the following activated features: and the javax namespace, it was possible to create an TransactionManager via the api dependency in the following way: We are moving to JakartaEE9 and this one API dependency seems not to have an equivalent for the jakarta.* namespace, so that this is not compiling: In the openliberty zip, see https://repo1.maven.org/maven2/io/openliberty/openliberty-runtime/22.0.0.1/openliberty-runtime-22.0.0.1.zip
Should I avoid big transaction and exclude read-only queries from transaction
I’ve seen articles saying that we should try to limit the scope of transaction, e.g. instead of doing this: We should exclude queryData from the transaction by using Spring’s TransactionTemplate (or just move it out of the transactional method): But my understanding is that since JDBC will always need a transaction for all operations, if I use the second way,
How to make an integration test with one transaction for all database calls and rollback it afterwards?
I’m, writing an integration test, annotated with @SpringBootTest. Suppose I create some product using pure SQL from my test, call calculation service that do some calculations based on it, and it calls another service to save those calculation results in different tables. What I need is to rollback all the changes made after test is finished. I read different questions,
Hibernate how to commit transaction even when exception pops up
i have a method in Service A And another method in Service B My problem is that when “repository.insertRandomValue()” throws ConstraintViolationException for example, then even tho it was caught in catch(), the thread ends with I have tried setting the propagation to REQUIRES_NEW and tried to set up transaction manager and GlobalRollbackOnParticipationFailure to false. I want it to simply ignore
Do I need transactional queues in Microservices?
I’m learning about microservices and I understand that in my scenario I want microservices to communicate with each other using message queues, with persistence. That means if the instance crashes and …
How to add transaction support to Java DSL integration flows
I have to add a transaction support to an integration flow. Let’s assume that there are 3 transformers. The first and third transformers should be done within the same transaction, but the second one shouldn’t be done within any transaction. Thus, if an error occurs in the third transformer, all changes from the first and third transformers should not be