We’ve seen our share of transaction conflicts. Owen’s suggestion (delay all db writes to a specific function that does the bare minimum and wrap only that function in the in_transaction decorator) is our basic approach.
These transaction conflicts appear to be very significantly increased when a search/get is made as part of a transaction. Most of the time for us, that search/get can safely be performed BEFORE the transaction lock is placed, because we don’t expect situations where the same rows would be handled by multiple users concurrently. So if you can do it, getting searches/gets done before starting a transaction is a really good place to start.
Feature request: This Read Committed thing @junderhill references seems like it would handle 99% of our use-cases… would be great if we could pass a parameter to the in_transaction lock for opt in to this!