Transactional Cache

Rational

Currently the Cache is partially transactional. There are cases where it could be filled with wrong data:

  • A transaction set some values which are not yet committed and if it fails to commit, those values stay in the cache.
  • A transaction clear the cache and it is filled directly by another transaction with older data.

Those are rare cases because only mainly static data are cached. But this is not a reason to not improve the situation.

Proposal

The idea is that modification of the Cache should be more “transactional” and reliable. A simple case is to allow to set in the cache only committed data. For that we could consider that a cache is always cleared when a transaction has modified the underlying data. So we should prevent a transaction that has cleared a cache to set data in it because those data will come from uncommitted transaction. Also in such case the cache should be empty only for the current transaction and cleared only when it is committed.
So basically this means that the get and set methods will use a new LRUDict for transactions who have called clear. On transaction commit, the new cleared LRUDict will actually replace this others. And on transaction rollback, the new LRUDict will be destroyed.
The _nocache attribute should prevent any usage of the Cache.

Implementation

https://bugs.tryton.org/issue7975
https://bugs.tryton.org/issue8019

1 Like

This topic was automatically closed after 14 days. New replies are no longer allowed.