Tryton - Issues

 

Issue9013

Title Wrong cache used for translations
Priority bug Status resolved
Superseder Nosy List ced, reviewbot, roundup-bot
Type behavior Components trytond
Assigned To ced Keywords review
Reviews 262841002
View: 262841002

Created on 2020-01-23.19:07:04 by ced, last changed by roundup-bot.

Messages
New changeset 2343104ebd57 by Cédric Krier in branch 'default':
Do use translation cache if records were modified after last synchronisation
https://hg.tryton.org/tryton-env/rev/2343104ebd57
New changeset f816cd0d481f by Cédric Krier in branch 'default':
Do use translation cache if records were modified after last synchronisation
https://hg.tryton.org/trytond/rev/f816cd0d481f
review262841002 updated at https://codereview.tryton.org/262841002/#ps262851002
review262841002 updated at https://codereview.tryton.org/262841002/#ps272791002
msg55010 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2020-01-23.19:12:45
Here is review262841002 which add on the Cache the method sync_since and pass to Translation.get_ids the datetime after which the cache can be used.
msg55009 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2020-01-23.19:07:03
When trytond is distributed across multiple processes, each instance has its own version of the cache. The synchronization of those caches is not instantaneous when one process clear its own. Generally it is not a problem because data stored in cache are almost static and there are not consequence in having for a short period processes with different value.
But this is not true for the translation. When a user changes a translation from a record, the client write the new value and reload the record. But as translations are stored in the cache, if the two operations (write and read) are not performed on the same process, the result may be awkward. Because the read request may return the value before the write and give the feeling to the user that its changes were not saved.

To solve this issue, I propose to use the translation cache only if its last cleaning is greater than the biggest modification date (write_date) of the records.
This will solve the described issue because the modification of the translation is done by writing on the record which updates the write_date. So the cache of other process will be skipped if they were not synchronized since the write.
This will not provide a big overhead because the record is already read from the table (we just need to read also the write_date). And the cache will still be used for record modified a long time ago.
History
Date User Action Args
2020-02-15 01:37:23roundup-botsetmessages: + msg55369
2020-02-15 01:37:06roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg55368
2020-01-23 20:22:59reviewbotsetmessages: + msg55013
2020-01-23 19:23:56reviewbotsetnosy: + reviewbot
messages: + msg55011
2020-01-23 19:12:46cedsetstatus: in-progress -> testing
reviews: 262841002
messages: + msg55010
keyword: + review
2020-01-23 19:07:04cedcreate

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