<br />A starvation scenario is what worries me:<br /><br />Lets say we have a slow complex transaction with many tables
involved.<br/>Concurrently smaller transactions begins and commits .<br /><br />Wouldn't it be possible for a
starvationscenario where the slower transaction will<br /> never run to completion but give a serialization failure
overand over again on retry ?<br /><br />If I know at what sql-statement the serialization failure occurs can i then
concludethat <br />some of the tables in that exact query were involved in the conflict ?<br /><br />If the
serializationfailure occurs at commit time what can I conclude then ?<br />They can occur at commit time right ?<br
/><br/>What is the likelyhood that there exists an update pattern that always give the failure in the slow transaction
?<br/><br />How would one break such a recurring pattern ?<br />You could maybe try to lock each table used in the slow
transactionbut that would be prohibitively costly<br />for concurrency.<br />But what else if there is no way of
knowingwhat the slow transaction conflicts against.<br /><br />As things with concurrency involved have a tendency to
popup in production and not in test I think it is important to<br />start thinking about them as soon as possible.<br
/><br/>Best Regards<br />Dan S<br /><br />