I have a multithreaded MQ worker in a ServiceStack service which is struggling with database locks. The retry mechanism is currently ensuring that the messages are eventually successful - but it is far from ideal , not very elegant and terribly non-performant.
While considering remediation (short of swapping out databases), I happened across this article on the Sqlite site talking about multithreaded and serialized mechanisms for write access - and was wondering if this is likely to bring some relief to the issue, and if there is are mechanisms for configuring this within Ormlite?
Compile time options is not possible without rebuilding the native .dll and creating new .NET packages of all Sqlite .NET .dlls to reference your custom SQLite build.
Calling the native sqlite3_open() is not possible in OrmLite which only references the managed C# ADO .NET Provider implementation of OrmLite which doesn’t directly call unsafe code that Pinvokes into the native .dll itself, the only way it could do it is by modifying the ADO .NET SQLiteConnection which doesn’t enable the configuration.
If they did support it, it would also typically be available as a connection string option which isn’t specified:
You would need to use a SQLite library that directly references the native .dll like sqlite-net:
understood - thanks, Demis. I suppose that ultimately the answer here is moving to a centralized RDBMS (like Postgres). In the interim I will try to tighten up my write connections and see if I cannot bring some relief by recycling them a little better…