Message 71063

Author
yangoon
Date
2021-10-18.09:00:50
Message id
71063

Content

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.

History
Date User Action Args
2021-10-18 09:00:51yangoonsetmessageid: <1634540451.0154305.QLRXJEGIJG6XKME6.issue10870@tryton.org>
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)