Skip to content

SQLite locking improvements for concurrent RPC#144

Open
domob1812 wants to merge 3 commits intomasterfrom
sqlite-locking
Open

SQLite locking improvements for concurrent RPC#144
domob1812 wants to merge 3 commits intomasterfrom
sqlite-locking

Conversation

@domob1812
Copy link
Copy Markdown
Member

The existing logic had some issues when many concurrent RPC calls were using the same read-only SQLite database snapshot for their logic (lock contention for some operations, and missing locks / race conditions for some others). This set of changes provides a comprehensive fix:

  • We use FULLMUTEX mode for all SQLite databases (SQLite handles locking correctly) instead of our own custom locking logic. This prevents actual locking bugs and race conditions.
  • We use the SQLite snapshot extension, which allows us to effectively "copy" an existing read snapshot. With this, we give each RPC processor its own, private database connection, so that there is no lock contention with any other RPC threads.

Both changes together should make the code more robust and stable on one hand, and also more performant on the other.

Remove manual locking of SQLite databases (which was missing some locks),
and just open each connection with SQLITE_OPEN_FULLMUTEX to enable
SQLite-internal full locking.

This solves potential locking issues, while it may increase lock
contention.  That will be fixed in a follow-up change.
This refactors the snapshotting logic.  Instead of having a fixed
two-layer hierarchy (SQLiteStorage parent, SQLiteDatabase child snapshot),
all snapshot handling now lives on SQLiteDatabase itself, and it supports
(in theory) a tree of snapshots.

We do not make use of this yet, but it will allow us in the future
to have snapshots (copies) of existing snapshots, to be used as
thread-local snapshots for RPC processing.
Use the SQLite snapshot extension, which allows us to get "exact copies"
of existing WAL read snapshots, for SQLiteGame.  In particular, we can use this
to give each RPC request its own, private database connection, which
can then be used without lock contention or locking issues with
any other RPCs running in parallel.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant