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 -- You received this bug notification because you are a member of OpenERP Indian Team, which is subscribed to OpenERP Server. https://bugs.launchpad.net/bugs/992525 Title: TransactionRollbackError due to concurrent update could be better handled Status in OpenERP Server: Confirmed Bug description: While using openerp, psycopg2 raises TransactionRollbackError quite often even on small database. This does not seem to be easily reproduceable as it seems to be a conflict between two thread accessing the same table. Nevertheless, I provided a quick video reproducing this while installing "base_crypt" on my computer. This occurs mostly at module installation. And can completely mess up the module installation by giving empty wizard windows of instance. I guess it could also occurs in other situations (in multi-user context), where the bug would be quite difficult to reproduce and with unforeseeable consequences ;) I've spotted an other bug that is due to this it seems: https://bugs.launchpad.net/bugs/956715 In my case (single user), it seem to hit more often on fast computers. To make a probable better guess, it seems to hurt more often whenever using a local connection between the browser and the server. It could be about the web module trying to update the res_users session info and may collide with normal operation. On my computer, from a new database, installing the 'base_crypt' will trigger the exception. When using a distant connection, the bug won't show up. Please check the video I've posted with the bug report if you want to have more detail on the procedure I used. Sorry for the bad sound recording. Note that the video will show you the bug occuring on my computer and NOT occuring on a distant computer. I'm providing a merge proposal along with this patch which solves the issue for me, but need a patient review. To manage notifications about this bug go to: https://bugs.launchpad.net/openobject-server/+bug/992525/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~openerp-india Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-india More help : https://help.launchpad.net/ListHelp
