Comment 3 for bug 992525

Here is some extra information concerning this bug report:

As discussed on the framework mailing-list[1] and on bug 746620, a TransactionRollbackError may happen under normal circumstances when a certain series of concurrent updates happen in an order that is not safe for the proper serialization of transactions. In other words, it is a fundamental safety mechanism that prevents corrupting data in case of concurrent updates to the same information.
As an example, think of a simplistic bank management system where 2 transactions would run at the same time, read "current balance: $100" and both withdraw $100 by saving "current balance: $0" - an obvious mistake as the final result should be -100$.
This cannot happen in OpenERP as accounting is using a double-entry system, but similar conflicts may happen for other kinds of data.

It is an "optimistic locking" strategy, which means that it will not make the operations block all the time when another operation is using the same resources (which would bring poor performance), but when a conflict is actually detected it will only allow the first transaction to complete, and rollback the orther, as if they had never occurred.
The user can simply retry the failed operation and it will work perfectly fine.

There is one way we could improve this system in OpenERP: we could automatically retry failed transactions after waiting a few milliseconds, because the chances are very high that on the second attempt the transaction will succeed (because the previously conflicting transaction has completed already). This means the user would not even see the failed transaction most of the times.

There is already an attempt to implement this (see the merge proposal linked to this bug), but the implementation is not finished/properly working yet.

[1] https://lists.launchpad.net/openerp-expert-framework/msg00818.html