[pysqlite] Concurrency - first steps
"Hugh Gibson" <hgibson-CVW/MsmY5bNaa/[email protected]> Tue, 4 Nov 2008 06:11 +0000 (GMT Standard Time)
| Newsgroups | gmane.comp.python.db.pysqlite.user |
|---|---|
| Message-ID | <[email protected]> |
For a long time we've used Python locks to control access to a database from multiple threads in PySQLite. However, given the latest work on GIL in PySQLite 2.5.0 I'm looking at moving to letting SQLite handle locking itself. I'm starting with a subsidiary database which needs fast access and might have a lot of throughput from many different worker threads. A couple of questions: The page http://oss.itsystementwicklung.de/download/pysqlite/doc/sqlite3.html#sqlit e3-controlling-transactions talks about "SQLites supported isolation levels: DEFERRED, IMMEDIATE or EXCLUSIVE". (Note, by the way, that EXCLUSIVE is given as EXLUSIVE earlier on in the document). However, http://www.sqlite.org/lockingv3.html lists UNLOCKED, SHARED, RESERVED, PENDING and EXCLUSIVE. What is the mapping to PySQLite's modes? The timeout parameter to a connection enables automatic retry of a statement. If that fails after a long time an exception is thrown. What sort of behaviour can reasonably be implemented if the timeout period expires? In our case I would just try to recommit - but should I look at sending some sort of "too busy" message back to the caller? What do other people do? Hugh