Hi,
The current ADO.NET SQLite provider reads:
"You May NOT call methods or properties or otherwise reference any SQLite
provider classes that belong to another thread.
You May NOT pass a SQLiteCommand, SQLiteDataReader, SQLiteDataAdapter or any
other SQLite provider class except a cloned SQLiteConnection to another
thread." My question is: Is it safe to share SQLite providers classes between
threads if all access to them is serialized inside lock (...) {...} statements,
or do they actually rely on thread local storage (in which case it would break)?
The reason is that I'm porting an exiting app that currently uses in-memory
object cache backed by an XML file. This app has a lot of data access made from
ThreadPool threads (typically IO callbacks) protected by lock(...) statements.
I don't want to create/prepare duplicate SQLiteCommand objects possibly for
each thread in ThreadPool. I could marshal all database calls to a dedicated
thread but that would result in extra complexity and probably a performance hit.
So before I do it, I wanted to ask if the existing approach with lock would be
enough for SQLite as well.
Thanks in advance,
- Levi
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
