[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Issue3854 was created for documenting sqlite3 vs. threads. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thanks, Martin. Commited as r66414. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-

[issue3846] sqlite3 module: Improved concurrency

Changes by Martin v. Löwis <[EMAIL PROTECTED]>: -- resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue3846] sqlite3 module: Improved concurrency

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > This has nothing to do with releasing/aquiring the GIL around > sqlite3_prepare, though. You mean, it doesn't make things worse, but I believe they do (even if so only slightly). If you have two threads simultaneously attempting an execut

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Just to be explicit: check_same_thread is unsupported and while it's undocumented in sqlite3, the old pysqlite docs say that when you use it, you have to make sure the connections/cursors are protected otherwise (via your own mutexes). [In th

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Interesting. I was smart enough to not document check_same_thread in the sqlite3 incarnation of the module. This has nothing to do with releasing/aquiring the GIL around sqlite3_prepare, though. Adding the macros was just an oversight. They'r

[issue3846] sqlite3 module: Improved concurrency

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Asking in the same direction: what is the consequence of this patch when check_same_thread is False? Couldn't that result in very problematic overlappings, e.g. when two threads try to execute statements on the same cursor? -- nosy:

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: 1. SQLite calling back Good that you mention it. During sqlite3_prepare, SQLite can call the authorizer_callback. Fortunately, it already acquires/releases the GIL appropriately already. 2. Other thread closing connection, etc. Connections/

[issue3846] sqlite3 module: Improved concurrency

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Your patch seems obvious, however: - Is there the possibility that sqlite3_prepare() calls back into a function in the _sqlite module or other python code? In this case the GIL has to be re-acquired. - What if another thread closes the

[issue3846] sqlite3 module: Improved concurrency

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- keywords: +needs review -patch priority: -> high ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3846] sqlite3 module: Improved concurrency

New submission from Gerhard Häring <[EMAIL PROTECTED]>: I'd really like this change to get into Python 2.6. It's pretty trivial (just releases the GIL when compiling SQLite statements), but improves concurrency for SQLite. This means less "database is locked" errors for our users. Could somebody