openerp-community team mailing list archive

[Juan Cristobal Lopez Arrieta <juancristobal@xxxxxxxxx>]

The concurrent updates are giving us so much trouble, that i have been
thinking to just comment the update for the login in res.user !!
or  replace it with an insert into another table (ie: res_user_login) ....
Sounds too much?


On Wed, May 15, 2013 at 10:00 PM, Eric Caudal <eric.caudal@xxxxxxxxxxxxxx>wrote:

>  We are in 7.0: we are checking whether this behavior in 6.1 is already
> available in 7.0 but so far not conclusive.
> By the way, we are using the latest python-psycopg.
>
>
>  Eric Caudal*CEO*
> --*Elico Corporation, Shanghai branchOpenERP Premium Certified Training Partner *
> Cell: + 86 186 2136 1670
> Office: + 86 21 6211 8017/27/37
> Skype: elico.corperic.caudal@elico-corp.comhttp://www.elico-corp.com
>
> [image: Elico Corp]
> On 05/15/2013 06:01 PM, Leonardo Pistone wrote:
>
>  Dear Eric,
>
>  I didn't have time to investigate, so that might not be relevant, but
> I've seen this commit on 6.1 recently:
>
>  http://bazaar.launchpad.net/~openerp/openobject-server/6.1/revision/4337
>
>  Leonardo
>
>
> On Wed, May 15, 2013 at 11:55 AM, Eric Caudal <eric.caudal@xxxxxxxxxxxxxx>wrote:
>
>>  Hi,
>> We have a case where our procurement scheduler (with procurement_confirm
>> and action_assign) is blocking other transactions (such as website
>> synchronization) or vice versa with an error such as "Serialized Access due
>> to concurrent update".
>> So far we have made some researches and we discover that this is maybe
>> due to an error " Repeatable Read Isolation Level", documented here:
>> http://www.postgresql.org/docs/9.2/static/transaction-iso.html
>>
>> A simple case would be like this:
>>
>> Session1: BEGIN;
>> Session2: BEGIN;
>> Session1: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>> Session2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>> Session1: SELECT * FROM tunnels WHERE un = 1 FOR UPDATE;
>>  un | password
>> ----+----------
>>   1 | bugsy
>> (1 row)
>>
>> Session1: UPDATE tunnels SET password = 'malone' WHERE un = 1;
>> Session2: SELECT * FROM tunnels WHERE un = 1 FOR UPDATE;
>> ...waits on Session1's lock...
>> Session1: COMMIT;
>> Session2: ERROR:  could not serialise access due to concurrent update
>>
>> In current OpenERP code, we have check and there are 3 main places where
>> this kind of transactions are used:
>> base/res_users.py for function login, line 334,
>> stock/stock.py, for function  _product_reserve line 442
>> stock_prodlot_wizard/prodlot_wizard, class stock_move_split_lines_exist,
>> line 279
>>
>> My questions:
>> 1. Is it something mandatory in standard code? What if we by pass/modify
>> them
>> 2. Would it be an option to commit more often?
>> 3. Is there any other reason why we could have this concurrent update?
>>
>> Suggestions are more than welcome!
>>
>> --
>>
>> Eric Caudal*CEO*
>> --*Elico Corporation, Shanghai branchOpenERP Premium Certified Training Partner *
>> Cell: + 86 186 2136 1670
>> Office: + 86 21 6211 8017/27/37
>> Skype: elico.corperic.caudal@elico-corp.comhttp://www.elico-corp.com
>>
>> [image: Elico Corp]
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Juan Cristobal Lopez Arrieta
http://www.openerp.com/node/560
skype  : jclopezar