Cache commit concurrent update with nested transaction
With the transactional cache (#7975 (closed)), 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 #7975 (closed), 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.