MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » June 2014

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



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact