SQLITE_OPEN_FULLMUTEX

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SQLITE_OPEN_FULLMUTEX

Prajeesh Prakash
Hi Members,

I enabled the SQLITE_OPEN_FULLMUTEX in that case if one thread is trying to write in to the DB and other thread is trying to read from the DB (Same connection). In that case will it cause any SQLITE_LOCKED error. In some of the forum i found that if we enable the SQLITE_OPEN_FULLMUTEX  the  sqlite handle ( sqlite3 * handle) contains the mutex filed so when the sqlite library is invoking that API will wait for the mutex to get open.



Thank you
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] SQLITE_OPEN_FULLMUTEX

Hick Gunter
Using SQLITE_OPEN_FULLMUTEX puts SQLite into serialized mode. This means that mutltiple threads can share a single connection but will block until the mutex is freed because the thread currently holding the mutex has left the SQLite code. Blocked threads will only experience a time delay (concurrency is reduced).

This is distinct from the SQLITE_LOCKED, which means that there is a (logical) conflict iin the same DB connection, e.g. attempting to drop a table in one thread while reading from the same table in another thread.

-----Ursprüngliche Nachricht-----
Von: sqlite-users [mailto:[hidden email]] Im Auftrag von Prajeesh Prakash
Gesendet: Mittwoch, 28. November 2018 08:33
An: SQLite mailing list <[hidden email]>
Betreff: [EXTERNAL] [sqlite] SQLITE_OPEN_FULLMUTEX

Hi Members,

I enabled the SQLITE_OPEN_FULLMUTEX in that case if one thread is trying to write in to the DB and other thread is trying to read from the DB (Same connection). In that case will it cause any SQLITE_LOCKED error. In some of the forum i found that if we enable the SQLITE_OPEN_FULLMUTEX  the  sqlite handle ( sqlite3 * handle) contains the mutex filed so when the sqlite library is invoking that API will wait for the mutex to get open.



Thank you
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___________________________________________
 Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] SQLITE_OPEN_FULLMUTEX

Prajeesh Prakash
That means (with SQLITE_OPEN_FULLMUTEX) if two threads are trying to do write and read to the table only one will get the chance to do the operation other thread needs to wait until the first thread finish its job . Am i correct

>
>     On November 28, 2018 at 1:24 PM Hick Gunter <[hidden email]> wrote:
>
>     Using SQLITE_OPEN_FULLMUTEX puts SQLite into serialized mode. This means that mutltiple threads can share a single connection but will block until the mutex is freed because the thread currently holding the mutex has left the SQLite code. Blocked threads will only experience a time delay (concurrency is reduced).
>
>     This is distinct from the SQLITE_LOCKED, which means that there is a (logical) conflict iin the same DB connection, e.g. attempting to drop a table in one thread while reading from the same table in another thread.
>
>     -----Ursprüngliche Nachricht-----
>     Von: sqlite-users [mailto:[hidden email]] Im Auftrag von Prajeesh Prakash
>     Gesendet: Mittwoch, 28. November 2018 08:33
>     An: SQLite mailing list <[hidden email]>
>     Betreff: [EXTERNAL] [sqlite] SQLITE_OPEN_FULLMUTEX
>
>     Hi Members,
>
>     I enabled the SQLITE_OPEN_FULLMUTEX in that case if one thread is trying to write in to the DB and other thread is trying to read from the DB (Same connection). In that case will it cause any SQLITE_LOCKED error. In some of the forum i found that if we enable the SQLITE_OPEN_FULLMUTEX the sqlite handle ( sqlite3 * handle) contains the mutex filed so when the sqlite library is invoking that API will wait for the mutex to get open.
>
>     Thank you
>
>     _______________________________________________
>     sqlite-users mailing list
>     [hidden email]
>     http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>     ___________________________________________
>     Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0
>
>     May be privileged. May be confidential. Please delete if not the addressee.
>
>     _______________________________________________
>     sqlite-users mailing list
>     [hidden email]
>     http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] SQLITE_OPEN_FULLMUTEX

Simon Slavin-3
On 28 Nov 2018, at 8:03am, Prajeesh Prakash <[hidden email]> wrote:

> That means (with SQLITE_OPEN_FULLMUTEX) if two threads are trying to do write and read to the table only one will get the chance to do the operation other thread needs to wait until the first thread finish its job . Am i correct

Are the two threads sharing the same database connection or do they each have their own connection ?

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] SQLITE_OPEN_FULLMUTEX

Prajeesh Prakash
Yes they are sharing the same DB connection

> On November 28, 2018 at 1:57 PM Simon Slavin <[hidden email]> wrote:
>
>
> On 28 Nov 2018, at 8:03am, Prajeesh Prakash <[hidden email]> wrote:
>
> > That means (with SQLITE_OPEN_FULLMUTEX) if two threads are trying to do write and read to the table only one will get the chance to do the operation other thread needs to wait until the first thread finish its job . Am i correct
>
> Are the two threads sharing the same database connection or do they each have their own connection ?
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] SQLITE_OPEN_FULLMUTEX

Keith Medcalf
In reply to this post by Prajeesh Prakash

SQLITE_OPEN_FULLMUTEX ensures that EACH CONNECTION is SERIALLY ENTRANT into the Sqlite3 library code (ie, that two threads cannot make a call into the library on different threads AT THE SAME TIME, or put another way that only ONE THREAD at a time on EACH CONNECTION may make a call into the library).  The Sqlite3 database engine code is only MULTIPLY ENTRANT on separate connections, but is required to be SERIALLY ENTRANT with respect to a (as in one) particular connection.  The default is serialized, or OPEN_FULLMUTEX, in order to prevent you from exploding something due to careless use of a connection in multiple threads.

Since transaction locking is handled at the CONNECTION level, if you use the same connection simultaneously from multiple threads they all share THE SAME ONE SINGLE transaction context.  In order to get an SQLITE_LOCKED response there must be more than one connection to the database, and one of those connections must be locking the database, in order for THE OTHER CONNECTION to get an SQLITE_LOCKED response.

There is no difference between using a SINGLE CONNECTION in a SINGLE THREAD or in MULTIPLE THREADS so long so long as you abide by the SINGLE ENTRANCE requirement.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of Hick Gunter
>Sent: Wednesday, 28 November, 2018 00:54
>To: 'SQLite mailing list'
>Subject: Re: [sqlite] [EXTERNAL] SQLITE_OPEN_FULLMUTEX
>
>Using SQLITE_OPEN_FULLMUTEX puts SQLite into serialized mode. This
>means that mutltiple threads can share a single connection but will
>block until the mutex is freed because the thread currently holding
>the mutex has left the SQLite code. Blocked threads will only
>experience a time delay (concurrency is reduced).
>
>This is distinct from the SQLITE_LOCKED, which means that there is a
>(logical) conflict iin the same DB connection, e.g. attempting to
>drop a table in one thread while reading from the same table in
>another thread.
>
>-----Ursprüngliche Nachricht-----
>Von: sqlite-users [mailto:sqlite-users-
>[hidden email]] Im Auftrag von Prajeesh Prakash
>Gesendet: Mittwoch, 28. November 2018 08:33
>An: SQLite mailing list <[hidden email]>
>Betreff: [EXTERNAL] [sqlite] SQLITE_OPEN_FULLMUTEX
>
>Hi Members,
>
>I enabled the SQLITE_OPEN_FULLMUTEX in that case if one thread is
>trying to write in to the DB and other thread is trying to read from
>the DB (Same connection). In that case will it cause any
>SQLITE_LOCKED error. In some of the forum i found that if we enable
>the SQLITE_OPEN_FULLMUTEX  the  sqlite handle ( sqlite3 * handle)
>contains the mutex filed so when the sqlite library is invoking that
>API will wait for the mutex to get open.
>
>
>
>Thank you
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>___________________________________________
> Gunter Hick | Software Engineer | Scientific Games International
>GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR:
>0430013 | (O) +43 1 80100 - 0
>
>May be privileged. May be confidential. Please delete if not the
>addressee.
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] SQLITE_OPEN_FULLMUTEX

Keith Medcalf
In reply to this post by Prajeesh Prakash

No, you are incorrect.  Isolation is only BETWEEN DIFFERENT CONNECTIONS, and has nought whatsoever to do with threads ...


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of Prajeesh Prakash
>Sent: Wednesday, 28 November, 2018 01:04
>To: SQLite mailing list; Hick Gunter
>Subject: Re: [sqlite] [EXTERNAL] SQLITE_OPEN_FULLMUTEX
>
>That means (with SQLITE_OPEN_FULLMUTEX) if two threads are trying to
>do write and read to the table only one will get the chance to do the
>operation other thread needs to wait until the first thread finish
>its job . Am i correct
>
>>
>>     On November 28, 2018 at 1:24 PM Hick Gunter <[hidden email]>
>wrote:
>>
>>     Using SQLITE_OPEN_FULLMUTEX puts SQLite into serialized mode.
>This means that mutltiple threads can share a single connection but
>will block until the mutex is freed because the thread currently
>holding the mutex has left the SQLite code. Blocked threads will only
>experience a time delay (concurrency is reduced).
>>
>>     This is distinct from the SQLITE_LOCKED, which means that there
>is a (logical) conflict iin the same DB connection, e.g. attempting
>to drop a table in one thread while reading from the same table in
>another thread.
>>
>>     -----Ursprüngliche Nachricht-----
>>     Von: sqlite-users [mailto:sqlite-users-
>[hidden email]] Im Auftrag von Prajeesh Prakash
>>     Gesendet: Mittwoch, 28. November 2018 08:33
>>     An: SQLite mailing list <[hidden email]>
>>     Betreff: [EXTERNAL] [sqlite] SQLITE_OPEN_FULLMUTEX
>>
>>     Hi Members,
>>
>>     I enabled the SQLITE_OPEN_FULLMUTEX in that case if one thread
>is trying to write in to the DB and other thread is trying to read
>from the DB (Same connection). In that case will it cause any
>SQLITE_LOCKED error. In some of the forum i found that if we enable
>the SQLITE_OPEN_FULLMUTEX the sqlite handle ( sqlite3 * handle)
>contains the mutex filed so when the sqlite library is invoking that
>API will wait for the mutex to get open.
>>
>>     Thank you
>>
>>     _______________________________________________
>>     sqlite-users mailing list
>>     [hidden email]
>>     http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>>
>>     ___________________________________________
>>     Gunter Hick | Software Engineer | Scientific Games
>International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a,
>HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0
>>
>>     May be privileged. May be confidential. Please delete if not
>the addressee.
>>
>>     _______________________________________________
>>     sqlite-users mailing list
>>     [hidden email]
>>     http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users