Issue 10870

Title
Lock table is not enough to ensure to read last committed values
Priority
bug
Status
chatting
Nosy list
ced, yangoon
Assigned to
Keywords

Created on 2021-10-18.00:52:57 by ced, last changed 1 month ago by yangoon.

Messages

Author: [hidden] (yangoon) Tryton translator
Date: 2021-10-18.09:03:46

Please ignore the stub in msg71063, it was posted by accident. I still have to reflect more...

Author: [hidden] (yangoon) Tryton translator
Date: 2021-10-18.09:00:50

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.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-10-18.01:22:34

This implementation could solve definitely the problem of issue6134.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-10-18.00:52:55

For now we lock tables during the execution of the code but as the doc explains it is not enough to ensure to read the latest values. Indeed we should lock the needed tables before any SELECT or UPDATE. The problem is that with the modularity and the OOP design of Tryton we do not know when starting the transaction which tables need to be locked.

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:03:46yangoonsetmessages: + msg71064
2021-10-18 09:00:51yangoonsetmessages: + msg71063
nosy: + yangoon
status: unread -> chatting
2021-10-18 01:22:34cedsetmessages: + msg71059
2021-10-18 00:52:57cedcreate

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