After encountering an error where different queues/messages were processing and changing the same row/table simultaneously or with open transactions, it was suggested by Pavel that this could be the cause. Based on this report and the errors on Sentry, I created an isolated scenario to test the problem.
The solution includes the following components:
- Docker Compose:
- RabbitMQ
- Rabbit queue seeder, creating 500 persons in an H2 database.
- Controller Endpoint:
- To replicate the problem, accessible at
("/replicateProblem").
- To replicate the problem, accessible at
Follow these steps to execute the project:
-
Start Docker Compose:
- Run the following command to build and start the containers in detached mode:
docker-compose up --build -d
- Run the following command to build and start the containers in detached mode:
-
Execute the Application:
- Start your Spring Boot application.
-
Replicate the Problem:
- Access the endpoint to replicate the problem:
http://localhost:8080/replicateProblem
- Access the endpoint to replicate the problem:
-
View Row Changes:
- Check the table in the H2 database. The specific row should have
version: 10, indicating 10 saves/updates (Total number of threads executed in the method)
- Check the table in the H2 database. The specific row should have
Different threads or pods are updating the same rows simultaneously. In a scenario where different queues and messages end up updating a specific row in a table in a multi-pod/thread environment, this can cause an error similar to:
The @Retryable annotation in Java, particularly with Spring, indicates that a method should be re-executed if specific exceptions occur. The retryFor property specifies which exceptions trigger retries, such as OptimisticLockException. The maxAttempts property defines the maximum number of retries, enhancing the application's resilience by handling transient failures gracefully.