Avoiding UnableToLockRowsToReadCurrentError exceptions about relstorage HOT 2 CLOSED

Those are all variations on (subclasses of) ZODB.POSException.ConflictError, itself a type of transaction.interfaces.TransientError. They indicate that ZODB's optimistic concurrency assumptions do not hold true: multiple transactions are trying to modify the same object, or objects that they depend upon. Thus, it is normal for applications that are writing concurrently to shared objects.

The only thing you can do about that (aside from either limiting your concurrency or designing your application not to write to shared objects) is to implement transaction retries. The higher the concurrency and the more objects are shared, the more transaction retries it will take. The transaction package has some limited support for that; other options include pyramid_tm, repoze.tm2, and nti.transactions. Last I looked, pyramid_tm and repoze.tm2 are specific to Pyramid and WSGI, respectively, while the mechanisms in transaction and nti.transactions can be used outside of those environments.

from relstorage.

Hi Jason,
I actually use the pyramid_tm package, and a default value of 3 retries in case of conflict error.
As the shared conflicting objects are probably part of the catalog, I just reduced client applications concurrency level... That's not a perfect solution but in my use case it's not a great problem, as documents integrity is the main point and it is a long but only one-shot process!
Best regards,
Thierry

from relstorage.