Cache concurrency

Hi,

I have a webapp with proteus, the problem is that sometimes happens a concurrent update trying to read some models with exceptions like:
“Exception calling model.sale.sale.read([319651], [‘total_amount’], {})”

This step is updating cache with this query:

‘UPDATE “ir_cache” SET “timestamp” = NOW() WHERE (“ir_cache”.“name” = %s)’
params: [‘modelview.fields_view_get’]

The error is:
could not serialize access due to concurrent update

I know that I’m doing something wrong but I don’t know how to deal with this, any hint?

Thank you :slight_smile:

PD: maybe 30 users are using the app at same time, peaks of 60 maximum

Concurrency error can happens at any times so you must live with them.
You can increase the number of retries.
Also if it is always the cache table that is the bottleneck, it means that you are modifying frequently data stored in the cache. So it is probably better to not store them in the cache. Now in your example, it is the cache for the view, so it is really strange to have such cache invalidation because it should be static, views and model do not change at production run time.

Side note, I’m working on a different implementation of the cache which will remove the ir_cache table bottleneck in exchange of more resource consumption.

1 Like

Is there any easy way to not store them in the cache? I’m a bit lost working with cache, I don’t know when data is stored on cache and how to verify/edit that. Is per model, is per whole app? Any link to documentation would be so helpful

edit: is this behaviour becouse of proteus? we use it in our python webapp, and each proteus call to our tryton is authenticated each time (tryton version is 3.4, thats why is not a beatiful api yet)

No, this is a standard behavior.

There is no general mechanism for caching. It is done case by case in some Model. But very few of them as cache, it is done only with mainly static data like views.
The mechanism is documented in Cache — Tryton server

I do not think so.

proteus is not really the right tool for that. You may have a look at Flask Tryton Module but you will need to upgrade to a supported version.

But the main question is why and how a call to model.sale.sale.read trigger a cache invalidation of the views. Such invalidation can only happen if one of the Models are changed: ir.action.*, ir.model*, ir.ui.view or ir.translation. But read call are read only by default.

1 Like

Ok so I will try to find why that call triggers that cache invalidation, thanks for your answers! :slight_smile:

PD: we are also working in parallel to upgrade the project to a newer version