Message 78569

Message id


For me, the proposal of locking all the tables at the beginning of the transaction has two problems:

  • It gives little granularity on locking. We already have problems when there're table-level locks (using version 6.0 locks the whole sale_sale table and that produces too much contention).
  • It still does not prevent the issue because when the lock occurs the transaction has already been started and so we can still have a scenario like the one described in issue11763: when the transaction starts the concurrent transaction is still running but when we try to acquire the lock the concurrent transaction has finished. This means that the second transaction can continue but the data it is seeing is already old.

So the only way I can think we can solve the issue is by locking before the transaction has been started, probably by using lock_id() in another transaction within the same RPC call.

It could be defined something like this:

cls.__rpc__['method'].locks = lambda ids: ids

If the dispatcher, found that locks is not empty it creates a transaction and inside it calls "lock_id(id)" for each of the ids returned by the method (calling it with all the IDs of the RPC request).

If all succeeded, then the usual transaction is called for the 'method'.

At the very end, the transaction with the locks is rolled back (or committed).

Date User Action Args
2022-10-04 15:26:42albertcasetmessageid: <>
2022-10-04 15:26:42albertcasetrecipients: + ced, yangoon, acaubet
2022-10-04 15:26:41albertcalinkissue10870 messages
2022-10-04 15:26:41albertcacreate

Showing 10 items. Show all history (warning: this could be VERY long)