2015-05-29 13:14 GMT+02:00 Raimon Esteve <[email protected]>: > 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? > > About NOWAIT: If NOWAIT is specified, LOCK TABLE does not wait to > acquire the desired lock
Also note that tryton locks the whole table even when two users are not competing for the same product. I created a review [1] some time ago to fix that although it eventually was commited something much simpler, you can dig in the reviews, where per product advisory locks were used. I think sooner or later some solution that is more fine grained than the current table lock will be required. [1] http://tryton-rietveld-hrd.appspot.com/999002/ > > note: > is a scenario related to [tryton] Large Scale Deployments, A > Discussion (3) when have multiples users working at same time with > trytond balancer = a lot user writing stock.move table. > > thanks > > (1) http://hg.tryton.org/modules/stock/file/d29329efc4b8/move.py#l753 > (2) > http://hg.tryton.org/trytond/file/71c72b11ec81/trytond/backend/postgresql/database.py#l370 > (3) https://groups.google.com/d/msg/tryton/O996ux1C_EQ/Rwd6cvI-8N4J -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
