After much investigation, I have concluded that the current implementation of transaction isolation is not correct. The result is unpredictable transaction rollback errors, and server deadlocks that can only be resolved by forcibly quiting the application and restarting it
The feature of transaction isolation is a bug and should not have been implemented in this version of the software. It is not suitable for production use. Transaction rollback is a common theme and is very easy to reproduce. OpenERP did not design the system to retry a transaction after a rollback. If a transaction rollback occurs it happens silently and makes no attempt to retry. This is a major architectural flaw. This can result in stock errors, data discrepancies, etc. The systems current state is not stable -- You received this bug notification because you are a member of OpenERP Indian Team, which is subscribed to OpenERP Addons. https://bugs.launchpad.net/bugs/1044054 Title: [6.1] abusive locking policy res_users (cascading shared lock) Status in OpenERP Addons (modules): New Bug description: 6.1 OpenERP implemented transaction isolation, and an abusive locking policy. Symptom: The transaction locking is very strict, specifically related to res_users table. In our production environment we have seen the issue where attempting to write to res_users, such as altering user data, or creating user groups will lock out the system completely. What happens is when you initiate a write query, it will be locked by itself. (didnt think this was possible). ANY other transaction initiated after the lock, will be locked by the res_user write. This creates a cascading shared lock on the entire system. This effectively disables openERP. We notice the issue more than others, because we use res_users to store printer data for our FedEx integration. They will change their printer based on the workstation they are at, and it will start the lockout. I could have 2 times per day that the server has to be reset because its all locked up by shared locks. Transaction isolation can be good, but there should not be such a strict locking policy on res_users. This can produce an unusable unstable environment. Instead of using a cover all policy, you should implement a system that selects locks based on tables, or operations. This issue also causes other issues in the system, all related to res_users. We have seen an issue where a user will alter a product, change the purchase price. When they click save it will display the gears for several minutes. This is not because its trying to write to product.product data, but its trying to write write_uid, and its related to shared lock. To manage notifications about this bug go to: https://bugs.launchpad.net/openobject-addons/+bug/1044054/+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
