[DocDB] TableLocks: Introduce support for an object lock manager #23045
Assignees
Labels
area/docdb
YugabyteDB core features
kind/new-feature
This is a request for a completely new feature
priority/medium
Medium priority issue
status/awaiting-triage
Issue awaiting triage
Comments
basavaraj29
added
area/docdb
yugabyte-ci
added
kind/new-feature
basavaraj29
added a commit
that referenced
this issue
Jul 30, 2024
…ck manager
Summary:
To achieve table locking, the high level proposal was as follows -
1. DMLs would acquire table/object locks at the local tserver, which need not be persisted since we don't need them post restart/crash (as all transactions hosted by the query layer at tserver would be aborted)
2. DDLs would acquire table/object locks at all the tserver, and the master leader would be responsible for re-acquiring these locks post tserver startup.
... other details not relevant for the current diff.
The earlier idea was to re-use the whole of conflict resolution path (acquire shared in memory locks + scan intent/regular db for conflicts + wait-queue ...) by creating a tserver local virtual transaction participant that maintains just one rocksdb instance for tracking the intents (and the suggestion was to tweak a few flags for this to be mostly be in-memory). It is important to note that the concept of transaction id is deeply rooted into all of this, and waiter resumption etc depend on txn status requests/ intent cleanup workflow triggered by transaction abort codepath etc.
Today, we don't start a distributed transaction until necessary (first read with explicit locks or a write in case of non serializable isolation levels start the distributed txn). But all the table/object lock request would/could be made prior to this. So the idea was to use some sort of a unique session id for acquiring the object locks. Plugging in the concept session id into the existing conflict resolution codepath doesn't go smoothly since there is lot of handling based on the "existence" of a transaction. Also, note that there is significant performance degradation for read only transactions if we always start a distributed transaction at the soonest, so we definitely need to go with the session id as a proxy.
In this diff, we try to re-use just the shared lock manager piece of the conflict resolution for achieving table locking feature.
`SharedLockManager` too does conflict resolution (checks conflicts during lock acquisition), but the scope of the lock is restricted to scope of the write rpc request itself using `LockBatch`.
This diff introduces the following
- templates `SharedLockManager::Impl` code to work with different key types as opposed to `RefCntPrefix` alone, and puts it all under `LockManagerImpl`
- adds support for a storing the acquired/waiting locks in-memory at the `ObjectLockManager` and thus not restricting the scope of the lock to the lifetime of the lock rpc request. For the core write path, we continue to restrict the scope of the in-memory locks to the scope of the rpc request.
- adds support for instrumenting locks on a session id granularity, thus allowing unlocking capability by providing a session id and optionally specific keys to unlock. Again, for the core write path, we don't instrument the in-memory locks.
With these enhancements to the `SharedLockManager::Impl` (now `LockManagerImpl`), the diff additionally creates an `TSLocalLockManager` maintained locally to every tserver that serves object lock/unlock requests. It also imposes a restriction that there can be at most one active lock/unlock request for any given session id actively being processed at the `TSLocalLockManager`. This is required for preventing invalid updates to the `LockState` of an object (an unlock should only be processed after a lock, else the unlock would be a no-op and the lock processed after it would leave the lock state in a corrupt state until process restart).
**Upgrade/Downgrade safety**
Introduced new proto messages, and new rpc service methods. No production usage of these yet, everything is guarded under a test flag `enable_object_locking_for_table_locks` which is default by false. The only usage of these is from `yb-ts-cli` for now.
Note: The `TSLocalLockManager` does not preserve the locks across tserver crashes/restarts, and that is the desired behavior for table locks. Also, there aren't any leadership concerns since every tserver has its own instance of the `TSLocalLockManager`.
Jira: DB-11977
Test Plan:
./yb_build.sh --cxx-test tserver_ts_local_lock_manager-test
./yb_build.sh --cxx-test='TEST_F(DocDBTableLocksConflictMatrixTest, TableConflictMatrix) {'
Also added lock/release api as part of ts-cli. To test manually, spin up a cluster using the following
```
./bin/yb-ctl create --rf=1 --data_dir ~/yugabyte-data --tserver_flags 'TEST_enable_object_locking_for_table_locks=true'
```
Can issue lock/unlock request using the following,
```
yb-ts-cli acquire_object_lock <session id> <object id> lock_mode
yb-ts-cli release_object_lock <session id> <object id>
yb-ts-cli release_all_locks_for_session <session id>
```
where lock mode is one of the following
```
ACCESS_SHARE
ROW_SHARE
ROW_EXCLUSIVE
SHARE_UPDATE_EXCLUSIVE
SHARE
SHARE_ROW_EXCLUSIVE
EXCLUSIVE
ACCESS_EXCLUSIVE
```
Reviewers: amitanand, myang, sergei, rthallam
Reviewed By: sergei
Subscribers: patnaik.balivada, esheng, ybase
Differential Revision: https://phorge.dev.yugabyte.com/D35822
jasonyb
pushed a commit
that referenced
this issue
Aug 1, 2024
Summary: 944bd87 [#23308] DocDB: Do not show InvalidFlags in flags UI 3c5c40a [DOC-328] [2024.1.1] Change data capture (CDC) Observability in YugabyteDB Anywhere (#22733) eb39516 [DOC-397] [2024.1.1] Create provider validation (#23039) e948dee [#DOC-348] Documentation for Migration Assessment in yugabyted UI. (#23288) 80835a8 [#23230] [DB Clone][YSQL]: Fix Cloning to a time before drop table in case of colocated databases 57e930e [docs] 404 fixes for July 5-19 (#23277) e166cee [PLAT-13956]: Fix RBAC test failure 7e10e9f [WIP][docs] Documentation for logical replication with PG connector (#23065) 86c4e4c [doc][2024.1.1] yb shell client download (#23170) a03ccda [#23045] DocDB: Support for table locks using tserver local object lock manager 836345c [doc][yba][2024.1.1] Kubernetes Prometheus (#23097) c842e1d [PLAT-14750]: Add runtime config to show the Premium V2 Storage type in case of Azure during Create/Edit scenario b0392f3 [PLAT-14734]: Highlight Decommission node status to indicate node is in bad or unhealthy state 307e2fc Fix the UT pipeline for local provider e0ff600 [PLAT-14696] DDL atomicity check metric and alert1 f229cc6 [PLAT-14739]: Make xCluster sync lock per config uuid Test Plan: Jenkins: rebase: pg15-cherrypicks Reviewers: jason, tfoucher Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D36955
Closed
1 task
basavaraj29
changed the title
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-11977
Description
For supporting table level locks, we would need some kind of object lock manager maintained at all tablet servers that satisfies the following
We could re-use the SharedLockManager code with some tweaks to achieve all of the above functionality.
Things that the shared lock manager lacks which would be essential for the object lock manager
Issue Type
kind/new-feature
Warning: Please confirm that this issue does not contain any sensitive information
The text was updated successfully, but these errors were encountered: