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