0

I am implementing Spring Retry, specifically for dead-lock scenarios, and there are several threads that get created further within my service (sending emails, etc).

The issue I am facing is the lack of control of whether or not these threads should retry again or not - since the retry attempt needs to be determined based on whether or not those threads triggered before the deadlock occurred.

How can I have some control over these thread creations?

Mark Park
  • 13
  • 1
  • 6
  • Spring Retry is completely passive; it creates no threads of its own; it runs on the calling thread. – Gary Russell Aug 02 '23 at 20:29
  • Right. But I have a large workflow where multiple services are being called on the main thread. During that main thread's process, I also create separate threads to run some tasks independent from the main thread itself. This is causing issues during retry because the independent threads will retry despite their success or failures. @GaryRussell – Mark Park Aug 03 '23 at 19:29
  • It's not at all clear what you mean; an example would be helpful. Your question was `>How can I have some control over these thread creations?` and you have answered yourself that you have total control. Spring retry is agnostic to whatever thread(s) it runs on. – Gary Russell Aug 03 '23 at 19:36
  • Hi @GaryRussell. Essentially, I have a workflow which will fall through different workflows depending on the request body. For example, a user is capable of actioning upon a particular task. Let's say they are approving something. After approvals, there are various rest template/api calls in order to retrieve some type of data pertaining to the request. And depending on the result of that data, we will fall through another process and update our data tables concurrently. This would be one layer of the workflow. There could possibly be 6-7 layers. At any point a dead lock can ... – Mark Park Aug 13 '23 at 19:26
  • occur. Within those 6-7 layers of workflow, we are constantly creating new threads to process some data, send some emails, etc. The problem is that all of this is done through one parent transactional annotation. Due to this, for any deadlock that occurs, a massive rollback occurs. A retry would resolve the deadlock and not cause any issues to the data-tables, however, since threads are being created throughout the workflow. These do not rollback. For example emails being sent don't roll back. And if I retry the same workflow, it would cause duplicate emails being sent out. – Mark Park Aug 13 '23 at 19:30
  • In future, don’t put extensive explanations in comments. The size is limited for a reason. Edit the question instead, and comment that you have done so. Spring Retry can’t help you in that scenario it, and Spring transactions, are bound to a thread. You also cannot expect non-transactional resources to act transactionally. – Gary Russell Aug 14 '23 at 13:35

0 Answers0