Describe the bug

SQLite implementation is not sufficient for preventing 'database is locked.' errors. SQLite allows near infinite reader concurrently, but it only allows one writer. A ReaderWriterLockSlim is the obvious choice for managing that.
Quartz.net simply does not have adequate abstraction of the database interaction to handle SQLite well. By my understanding, you can open a connection to SQLite, but BEGIN TRANSACTION and COMMIT TRANSACTION is where the locking needs to be done.
There are some abstractions for locking, but GetConnection() isn't included in that, and GetConnection() begins a transaction when called.

Solution:
I would separate the ExecuteInNonManagedTXLock() into ExecuteInNonManagedReadLock() and ExecuteInNonManagedWriteLock(). I don't think ExecuteWithoutLock() should exist, at all. If a read doesn't require a lock, then it just won't lock in ExecuteInNonManagedReadLock(). ISemaphone could be changed to have ObtainReadLock(), ObtainWriteLock(), ReleaseReadLock(), and ReleaseWriteLock().

As an aside, WAL could be implemented by executing a command on connection. That would improve a lot.

Version used

3.8.0