Re: pysqlite design decisions
Gerhard Häring <[email protected]>
| Newsgroups | gmane.comp.python.db.pysqlite.user |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Boos wrote: > glyph-TyWPi3/[email protected] wrote: >> ... >>> | I've heard, sqlite itself is only middling good at dealing with multiple >>> | threads. >>> >> >>> You heard wrong. >>> >> The impression may simply have been garnered from the proximity of threading bugs to database bugs in extremely poorly tested projects such as Trac. >> > > Pleased to hear that ;) > Agreed, in Trac we had a bunch of issues with multi-threading, locks, > etc. but in the process we also helped to improve the bindings in this > area. And I think that with SQLite (>= 3.3.4) and recent pysqlite, the > infamous "database is locked" issue doesn't happen anymore in 0.10.2 and > 0.11dev, thanks to the ability to pool the connections and reuse them > from one request/thread to the next. I hate that issue. Really hate it. Really REALLY hate it. Because the question wether you can share pysqlite connections among threads comes up every so often, and I cannot give an honest answer. I searched hard and read http://sqlite.org/faq.html#q8 again, and again. According to that, sharing is only *really* safe if all statements are finalized, and that's certainly not the case with pysqlite connections, because you can be pretty damn sure that the connection contains prepared statements that are in *reset* state, but not *finalized*. It may even be possible that a transaction is still open. That's why the check_same_thread is still True by default. I even went as far as documenting that flag not at all in the sqlite3 module so a) I don't have to answer that annoying questions :-P b) I can remove the check when I'm certain SQLite is really threadsafe enough one day without it - -- Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdfHLdIO4ozGCH14RAvpfAJ9BAMOxPkq05x0sVY/rq7ldrCTtiACfewpS Qe6o8uOLqoyN6jh9R0fWSrI= =4bDT -----END PGP SIGNATURE-----