NativeSqliteDriver

Native driver implementation.

The driver creates two connection pools, which default to 1 connection maximum. There is a reader pool, which handles all query requests outside of a transaction. The other pool is the transaction pool, which handles all transactions and write requests outside of a transaction.

When a transaction is started, that thread is aligned with a transaction pool connection. Attempting a write or starting another transaction, if no connections are available, will cause the caller to wait.

You can have multiple connections in the transaction pool, but this would only be useful for read transactions. Writing from multiple connections in an overlapping manner can be problematic.

Aligning a transaction to a thread means you cannot operate on a single transaction from multiple threads. However, it would be difficult to find a use case where this would be desirable or safe. Currently, the native implementation of kotlinx.coroutines does not use thread pooling. When that changes, we'll need a way to handle transaction/connection alignment similar to what the Android/JVM driver implemented.

https://medium.com/androiddevelopers/threading-models-in-coroutines-and-android-sqlite-api-6cab11f7eb90

To use SqlDelight during create/upgrade processes, you can alternatively wrap a real connection with wrapConnection.

SqlPreparedStatement instances also do not point to real resources until either execute or executeQuery is called. The SqlPreparedStatement structure also maintains a thread-aligned instance which accumulates bind calls. Those are replayed on a real SQLite statement instance when execute or executeQuery is called. This avoids race conditions with bind calls.