Table lock

[grecinto]

A good future feature of SOP is support for "exclusive write" lock. So, when in an exclusive "write" lock, a Btree can have full ownership of the Btree tree. I.e. - since it has "write" table lock, it does NOT need to check for version conflicts on commit.

Other SOP transactions can only do "read only" on this Btree that is "write" locked on the table level. Also, since the Btree is write exclusive, the transaction can optimize that the Btree will retain the cache data across transactions.

So, in a way, this can allow a Btree to perform like a traditional Btree, a monolith which Nodes' are always "cached".

There are many use-cases that the current v2 SOP is optimal, like it works like a swarm in the cluster. BUT there are use-cases that an "exclusive write" lock on the table level can bring. And that will further increase the efficiency of SOP, as it covers far & wide diverse use-cases in storage management & rich search scenarios.

Today, each Btree has local cache (L1) within the transaction and it gets cleared on commit. This works fine BUT on cases where one wants to process entire table, this works fine too as the Redis cache that serves as L2 will rehydrates the local cache. However, an exclusive locked Btree is awesome that it can allow SOP to bypass version checks & retain this local cache and implement MRU in it.

So, the table "write" lock is really so much beneficial. In fact, it is the answer to cover the last mile (use-case) as described.

[grecinto]

It is thought that the table lock can be specified, that is, either "read" or "write" locks when opening it. Example, OpenBtree(.., forReading) will open the btree and attain to get it locked so succeeding cluster Btree open instruction can only be allowed "forReading". Any "forWriting" open attempt will fail right away, rollback the transaction.

Same thing when a Btree is in "forWriting" mode, any succeeding Btree open instruction for writing will fail, but for reading will be allowed. They will be able to read the currently committed version of the data.

This has to be worked out so it will work complementary to transaction mode of "forWriting" and "forReading".

[grecinto]

Closing this item for now, 'will just re-open when time permits, or when volunteer is taking ownership to implement this.