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.