Issue 8447

Cache commit concurrent update with nested transaction
Nosy list
ced, reviewbot
Assigned to

Created on 2019-06-21.17:52:01 by ced, last changed 21 months ago by ced.


New changeset 3e357bf75021 by Cédric Krier in branch 'default':
Use separate connection to query cache table
New changeset 634f8347fb75 by Cédric Krier in branch 'default':
Use separate connection to query cache table
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2019-06-21.17:52:00
With the transactional cache (issue7975), the sync and commit of the cache is done using the current transaction.
The problem is that on long transaction, if the sync is called, it keeps a lock on the ir.cache records until the commit. If a second transaction update this record meanwhile the first transaction fails. This can happen when using Transaction.new_transaction().
Before issue7975, the problem did not exist because those methods were done in a new transaction. At some point, we must restore this behavior to read/update ir.cache records. It will not break the transactional behavior because at worst the cache transaction is committed but not the main one and we just have a unnecessary cleaning of the cache.
Date User Action Args
2019-07-22 21:38:43cedsetkeyword: - backport
2019-07-08 21:25:04cedsetstatus: testing -> resolved
2019-07-08 21:24:56cedsetstatus: resolved -> testing
nosy: - roundup-bot
keyword: + backport
2019-07-08 21:24:52roundup-botsetmessages: + msg50568
2019-07-08 21:24:47roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg50567
2019-06-25 12:20:04reviewbotsetmessages: + msg50377
2019-06-25 09:52:52reviewbotsetmessages: + msg50376
2019-06-23 22:48:29reviewbotsetmessages: + msg50365
2019-06-21 18:07:12reviewbotsetnosy: + reviewbot
messages: + msg50360
2019-06-21 17:56:50cedsetstatus: in-progress -> testing
reviews: 283591002
keyword: + review

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