Closed domob1812 closed 3 years ago
The last commit had to be partially reverted with 84ff3e64cdcdc5b651cea5899bde9ff1c68ceec1. Even if a prepared statement is only used from one thread, we have to lock the underlying database connection when stepping it.
This refactors the SQLite database integration (
SQLiteDatabase
as used forSQLiteStorage
andSQLiteGame
). Instead of exposing prepared statements throughsqlite3_stmt*
, we wrap them into a custom utility class. It supports binding of parameters and extracting of column values, which simplifies life for particular GSP implementations (which so far basically duplicate that code in each).With that
Statement
class, we can also use RAII semantics to "fix" the statement cache to be properly "recursive" and thread-safe. Instead of a single cached instance for each SQL string, we now may have multiple, and properly lock/release them as needed. This allows a single thread to concurrently use two statements of the same SQL string, and also allows proper multi-threaded usage of a database (where each thread can have their ownStatement
instances).Finally, since statements become thread-safe with this change, we no longer really need SQLite to run in serialised mode (doing locking internally). Instead, we can run it in the faster multi-threaded mode, and just lock the
sqlite3*
manually in addition to the already thread-safe statement cache. This improves performance of e.g. the Taurion GSP by a couple of percent.