×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
