openerp-india team mailing list archive

["Kyle Waid - http://www.gcotech.com" <1044054@xxxxxxxxxxxxxxxxxx>]

** Description changed:

  6.1 OpenERP implemented transaction isolation, and an abusive locking
- policy. In a production system with many concurrent users accessing the
- system 20-30 + if most actions are performed on table res_users it will
- lock out the system until its transaction is finished.
+ policy.
  
- We have experienced issues, where the system frequently becomes
- unusable. A case scenario would be  a user altering a purchase price of
- a product, it updates uid, and date. It hangs on this query for several
- minutes. The result is that the user sees the gears spinning for several
- minutes. It is not a performance issue, but 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. 
  
- Another issue, we were not able to create new user groups. This is
- because it seemed the table was locked, this caused a transaction wait.
- Other transactions became locked, waiting for the group query to create.
- It results in a cascading lock, meaning that no user can use the system
- effectively disabling the system.
+ 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.
  
- This is a regression from 6.0, that did not suffer from such an issue.
- An example from postgres showing the shared lock, and queries that were
- being blocked in a cascaded fashion
+ 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.

** Summary changed:

- [6.1] abusive locking policy res_users
+ [6.1] abusive locking policy res_users (cascading shared lock)

-- 
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