fnc12/sqlite_orm

Why sqlite_orm doesn't use sqlite3_open_v2() to let it be thread-safe?

Opened this issue · 2 comments

yangsongx commented

I know the sqlite3_open_v2() can support the therad-safe. But it didn't be called by sqlite_orm.h

Can I just replace the sqlite3_open()/sqlite3_close() with sqlite3_open_v2()/sqlite3_close_v2() to let sqlite_orm.h be thread-safe?

Or , is the default sqlite_orm.h already be thread-safe?

(PS, I knew the sqlite3 needs to enable the ./configure --enable-threadsafe to let it support thread safe in Sqlite3 itself)

fnc12 commented

where did you find that sqlite3_open_v2 make the connection thread-safe?

yangsongx commented

Hi, Thanks for you reply.

https://www.sqlite.org/c3ref/open.html

The sqlite3_open_v2() interface works like sqlite3_open() except that it accepts two additional parameters for additional control over the new database connection. The flags parameter to sqlite3_open_v2() must include, at a minimum, one of the following three flag combinations:

There is a flag in the sqlite3_open_v2():
[SQLITE_OPEN_FULLMUTEX]

The new database connection will use the "serialized" threading mode. This means the multiple threads can safely attempt to use the same database connection at the same time. (Mutexes will block any actual concurrency, but in this mode there is no harm in trying.)

And it also provide sqlite3_busy_handler() API to let caller to keep waiting when writing to DB with multiple threads.

related description:

  - https://www.sqlite.org/c3ref/busy_handler.html
 - https://www.oreilly.com/library/view/using-sqlite/9781449394592/re238.html