openerp-india team mailing list archive

[Kyle Waid <1044054@xxxxxxxxxxxxxxxxxx>]

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