2015-05-29 13:28 GMT+02:00 Cédric Krier <[email protected]>: > On 29 May 13:14, Raimon Esteve wrote: >> Hie, >> >> when assign stock move, try_assign lock table (1). In Backend >> PostgresSQL, the lock is NOWAIT (2). >> >> When two or more users try to assign shipments at same time, "second >> user" get a nice error. >> >> Traceback is: >> >> File "/shipment.py", line 1292, in assign_try >> for m in s.inventory_moves]): >> File "/move.py", line 754, in assign_try >> Transaction().cursor.lock(cls._table) >> File "/trytond/backend/postgresql/database.py", line 359, in lock >> self.cursor.execute('LOCK "%s" IN EXCLUSIVE MODE NOWAIT' % table) >> OperationalError: could not obtain lock on relation "stock_move" >> >> Why lock() method in PSQL backend add NOWAIT option? Why not waiting >> next user request when unluck table and continue try_assin? the >> reason? > > because the transaction of the waiting user is already started and so it > must be restarted to have the new committed data. > > On such operational error, trytond retries 5 times per default [1] if it > is not enough for your setup you should increase it. > Or maybe you have a too long transaction keeping the lock, in such case > you must reduce the time of this transaction.
Yes, it is => A transaction is very longer. For example, try assing 500 shipments it will be spent some long time (~ 10 o 15 minuts) and stock.move is locked. In this case, increase retries option can't work. I think we could do transaction in blocks (for example, each 10 shipments) to lock/unlock table and other transaction could do some task.
