I am using Dapper with my SQLite database. I have developed some multi-threaded code where each thread performs some read and write operations using Dapper ORM. Both the thread may very much try to concurrently write on the same table as well.
The confusion I am facing is that do I have to implement some technique in my code to make the concurrent reads thread safe or do dapper will handle that for me.
Do note I am familiar that SQLite is the one locking the db file for write and my only concern here is about Dapper and what it does in such scenario.
As you said, SQLite implements locking on DB file level.
Dapper or any other full or micro ORM cannot change this fact. No ORM will implement thread management or concurrency for any RDBMS. Thread management is responsibility of user.
Think other way. How ORM will know how to implement threading?
Yes; some ORMs manage connection up to certain level. But mostly, it is only limited to creating/opening/disposing it. ORMs do not control threading or concurrency. It is something to be implemented by user.
Response to your comment:
but yet the question still stays what dapper does in such cases as it may have some sort of retry logic to try execute the query again in case the lock is there
Dapper don't do anything like that. Dapper works exactly (well... almost) like ADO.NET. For any querying part, Dapper is not much functionally different than ADO.NET.
So, to answer your comment, if some provider of ADO.NET implement retry logic, it will be inherited by Dapper automatically. But, Dapper on itself do not implement any such logic.
If I guess correctly, ADO.NET will throw proper exception - Dapper will simply pass on that exception to you.
I hope this answer will help you.