Community mailing list archives

community@mail.odoo.com

Re: Odoo Performance and concurrency locks

by
OpenERP Master
- 09/15/2015 23:56:33
I do not think removing gapless sequences is an option, but I could be misunderstanding something. A sales order increment and other documents are a postgres sequence right? If I understand correctly, this change would guarantee a gap in sales order numbers. Many companies in the United States would not like this behavior, and in some countries like Germany, it is a legal requirement to have no gap in document numbers.

On Tue, Sep 15, 2015 at 2:47 PM, Gustavo Marino <gamarino@numaes.com> wrote:
Olivier:
>On 09/14/2015 06:28 PM, OpenERP Master wrote:
>> The part you said in 2a, I can see this at any point while a transaction >is
>> executing, it does not have to be the beginning.

>It does not have to be the beginning. But the login transaction can only abort 
>another transaction *if and only if* the other transaction:
>  - had started (or restarted, for background jobs) before the login
>  - had not taken any shared/exclusive lock on the res.users record yet
>  - is going to take a shared/exclusive lock on the res.users record later
>    (Shared locks on res.users are most commonly taken via the 'create_uid'
>     foreign keys of any record being created/updated.)
You are presenting this case as exceptional. In fact, any transaction that has created an object will not fullfill your requirements (because of the create_uid/update_uid). In other words every long or short running transaction, that creates objects, will be aborted by Postgress on the next login, just because Odoo does not accept to move the almost unused last login to a separated table and thus, avoiding the problem.
Why is it so difficult to accept the suggestion to ensure no writing to user record on logging? Which is the critical issue behind? Just implement it now, before v9 release, no patch will be required later


Gustavo Adrian Marino

 

Mobile:  +54 911 5498 2515

Email: gamarino@numaes.com

Skype: gustavo.adrian.marino

 

<img border="0" width="213" height="94" src="cid:image001.jpg@01CC37F5.99B4CD20" alt="Descripción: Numa Logo V 1-0">



2015-09-15 15:10 GMT-03:00 Olivier Dony <odo@openerp.com>:
On 09/14/2015 06:28 PM, OpenERP Master wrote:
> The part you said in 2a, I can see this at any point while a transaction is
> executing, it does not have to be the beginning.

It does not have to be the beginning. But the login transaction can only abort 
another transaction *if and only if* the other transaction:
  - had started (or restarted, for background jobs) before the login
  - had not taken any shared/exclusive lock on the res.users record yet
  - is going to take a shared/exclusive lock on the res.users record later
    (Shared locks on res.users are most commonly taken via the 'create_uid'
     foreign keys of any record being created/updated.)

If those conditions are not met, the login transaction will execute without 
interrupting anyone, or will simply skip updating the user because it won't be 
able to get an exclusive writer lock (FOR UPDATE).
This definitely requires unusual conditions, and only works before PG 9.3.

After 9.3 the login update will only grab a "FOR NO KEY UPDATE" lock on the 
user (because it does not touch the PK), and the FK will only require a "FOR 
KEY SHARE" lock, so there won't be any possible conflict between them.

Don't take my word for it, read the PG manual and convince yourself using two 
`psql` consoles and isolation level REPEATABLE READ.
It's the best way to really understand the mechanics of transaction isolation.

Upgrading to PG 9.3 is trivial, virtually risk-free and will provide better 
performance, so whenever you see problems with TransactionRollbackError, this 
is your first and most important step.

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe