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 <[email protected]>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: [email protected]http://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 > <[email protected]>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: [email protected]http://www.elico-corp.com >> >> [image: Elico Corp] >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > 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
<<image/jpeg>>
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
