Re: Identifying an Object Lock, after the fact...

On 10-Jun-2014 12:26 -0500, Graap, Kenneth wrote:

<<SNIP>> Is there a way to identify what cause an object lock
conflict AFTER the jobs have ended and without having started a
Performance Trace prior to the event happening?

Not really, unless the lock holder persisted; i.e. the responsible lock holder is not one of those jobs that has ended.

However inference is often possible given some amount of details about the failing scenario. Or a strategy can be put in place to help identify a conflict given knowledge of the processing and the expected failure if the failure is known to occur somewhat solidly or just periodically; effectively, ensure an often-failing requester holds a conflicting lock what will hopefully cause the other temporal conflicting requester to fail instead so then information from two failing requests [from either side] is available. Another strategy for identifying a lock holder is also possible, as a purely exception-driven attempt; i.e. change the failing code to display the locks held for the object in conflict, immediately upon receipt of the exception, which is so much faster than any human can possibly react.