Discussion on "Implementing Automatic Retry for Database Deadlocks in Spring Boot using Spring Retry"

Taehyeong Lee · 2024-01-16T06:45:08.152Z

Overview Lack of experience in handling deadlocks in databases can lead to panic during the most critical moments when a production-level system faces a high influx of customers. No matter how clearly you write business logic or how thoroughly you c...

Thanks to you, I was able to think deeply about lock and isolation. Thank you!

You have set the @Transactional annotation on the Repository interface. I usually prefer to declare it in the Class method of the Service layer... Is it a better practice to declare it in the Repository?

Of course, it is most commonly used in concrete classes at the Service level :) In this example, I wanted to introduce you to the lowest level where you can use @Transactional in your project, so I showed you an example of specifying it in the @Repository interface. I make it a habit to specify @Repository and @Service, because that way I can cope with both transactions from real-time APIs with low execution time, and logic that has hours of execution time and intentionally doesn't use service-level transactions.

Taehyeong Lee Thank you for the response. I also plan to develop a habit of doing so. By establishing a solid foundation, it seems possible to preemptively prevent deadlocks that may occur in unexpected areas.

Thanks to you, I was able to contemplate about lock and isolation.

In source code, you implemented the @Transactional annotation in the Repository Interface, but according to Spring documentation, they recommend setting it at the class level.

how do you think about it?

docs.spring.io/spring-framework/reference/data-ac…

---- I discovered this after making the comment ---- It seems that the Repository with Data JPA interface is an exception where it's permissible to use Transactional.

It also works well to specify @Transactional in a custom method of the Spring Data JPA interface, as in this example. This brings a lot of convenience to the developer, as they don't have to re-write each custom query with @Transactional in an outer contained class. In typical real-time business logic, most of the time the transaction propagation setting will use the default value of Propagation.REQUIRED, so you can also naturally carry over transactions created at higher Service levels.

Discussion

Implementing Automatic Retry for Database Deadlocks in Spring Boot using Spring Retry

Responses(2)

Recent in Forum

Search Hashnode

Implementing Automatic Retry for Database Deadlocks in Spring Boot using Spring Retry

Responses(2)

Recent in Forum