I have read many websites talking about how to avoid and how to design etc. I completely understand those strategies.
My question is based on the following preconditions:
- You have a company with 1000's of developers.
- There are different teams working on the same product but as modules.
- New developers writing new code not knowing the overall system, please consider an Enterprise application.
- High available software development where a downtime of 15 mins is considered as an SLA violation.
I could write few more preconditions but I thought these could be strong enough to support my question about why I might need a recovering strategy for a "Deadlock" in a software.
Please note that re-designing the modules whenever we find a deadlock is not realistic.
Now this being said.
Can someone take sometime to provide an input or brainstorm on an idea of how to resolve a deadlock if at all it happens, so that we can report it and move forward, instead of halting completely.
- Run a deadlock detector that runs periodically to look for deadlocks in the system.
- If a deadlock is detected, notify with an event to resolve the deadlock.
- The deadlock event listener will then kick in and act upon the deadlocked threads.
- For each thread identify the contention.
- Write an intelligent algorithm that could either release the locks and kill the thread or release the locks and re-evaluate the thread.
- In step 2 we handle the notification in multiple ways, out of which logging is one of the listener.
I know how to go about steps 1,2,6. Will need help with 3,4 and 5.
I know that Oracle RDBMS already has a deadlock detection and resolution strategy in place, I wonder if they would ever share their strategies in this thread :)
Can't add my comment as an answer so adding it as a comment here.
I completely understand the risk of killing the threads. I was 100% certain that I would get answers like this but I was also hoping that someone would suggest something new. I'll keep the thread open as there is no answer in here that I already do not know, thank you very much for trying though.