Message 71063

Message id


I think a possible design would be to add an argument to Transaction.start
as a list of tables to lock. Now when the backend is called to lock a table,
it checks if it is a table already locked by the start of the transaction. If
it is not than it raises an exception that is catched by the starter of the
transaction which is responsible for adding the table to the list to lock
when re-starting the transaction.

Those difficulty could be avoided by using SERIALIZABLE isolation. This mode
is not available for now (we replaced by REPEATABLE READ) but maybe we could
allow to declare the need for such transaction (maybe depending on the tables
to lock) and in this case the LOCK calls and SELECT FOR could be ignored.

Date User Action Args
2022-02-05 10:05:05cedunlinkissue10870 messages
2021-10-18 09:00:51yangoonsetmessageid: <>
2021-10-18 09:00:51yangoonsetrecipients: + ced
2021-10-18 09:00:50yangoonlinkissue10870 messages
2021-10-18 09:00:50yangooncreate

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