|
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 branch OpenERP Premium Certified Training Partner Cell: + 86 186 2136 1670 Office: + 86 21 6211 8017/27/37 Skype: elico.corp [email protected] http://www.elico-corp.com  |
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
