Keep a Lua object in-sync with a space (for caching purposes)

[Totktonada]

Thoughts how to make caching of a space content better spins in my mind for a while. I filed an issue for exposing instance local schema version, another one to bump schema version at change in a non-system space. It should help with tracking of space changes.

The starting point was the issue regarding caching of a sharding function in the tarantool/ddl module (see 4th bullet). I continued thinking on it in this discussion in the linked pull request. And here I started the discussion on tarantool API to make it easier (and fully correct).

If we aim to implement a fully transparent caching of space data inside a Lua object, we should change our Lua object (cache) synchronously with space changes: so a caller should see exactly what (s)he would get from the space. And here we go into the problem with transactions: a particular state of the Lua object should be visible from one transaction and should NOT be visible from another. Moreover, a transaction can be rolled back and the Lua state should be rolled back as well. We have no mechanism to implement such behaviour in Lua (we don't ever have a transaction id here).

In my mind it should work as (or similar to) RCU pattern (read-copy-update). Say, we have a committed space state (+cache in Lua). If it is going to change, we copy the Lua object (likely using a user defined Lua function) and change the copy. If the transaction is committed, the old object is replaced with the new one. All accesses to this object should go via an API, which gives correct version of the Lua object to the caller.

What else spins in the head:

• How to determine that the Lua object should be copied? A user should assign a space id/name for a particular caching Lua object? Whether someone want to track several spaces in one object?
• We can track space data changes using on_replace() trigger, but it'll miss space drop + create. In theory we can set a trigger on _space as well, but 1) it is unclear, when exactly we have enough permissions for that; not sure that always when we own the space; 2) here we'll track all space changes, while we're interested in just one space; so any _space change will lead to invalidating of all such Lua caches.

[R-omk]

And here we go into the problem with transactions: a particular state of the Lua object should be visible from one transaction and should NOT be visible from another. Moreover, a transaction can be rolled back and the Lua state should be rolled back as well.

as a simple dirty solution just skip cache read if transaction is started and onyield event happened

[Totktonada]

If you're about 'how to implement it now in Lua', then:

1. There is no Lua API for setting up an on_yield() trigger.
2. We anyway should handle box.rollback().
3. And so it ends with 'don't use the cache in a transaction' variant, which is not always acceptable due to performance reasons.

If you're about possible implementation in tarantool, I hope that it would either be full or should not exist.

[R-omk]

There is no Lua API for setting up an on_yield() trigger.

Sorry, I confused, it seemed to me what api was added to lua

don't use the cache in a transaction

In general, my thought was just that. Means use cache for read only

[Korablev77]

Moreover, a transaction can be rolled back and the Lua state should be rolled back as well.

Unfortunately it does not work even now: #6470

[Korablev77]

Anyway idea seems to be cool but requires careful consideration. I'd be glad to help and participate since I've already worked on transactional ddl a bit.