Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #37101
| From | Lie Ryan <lie.1296@gmail.com> |
|---|---|
| Subject | Re: Vote tallying... |
| Date | 2013-01-20 12:15 +1100 |
| References | <50F8906D.9040203@r3dsolutions.com> <kdb27d$udr$1@ger.gmane.org> <50F9518E.3040509@r3dsolutions.com> <kde1on$fcs$1@ger.gmane.org> <ja3mf8pfej2mtp1qpdosla1q857chuhrpn@invalid.netcom.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.702.1358644515.2939.python-list@python.org> (permalink) |
On 20/01/13 08:22, Dennis Lee Bieber wrote: > On Sat, 19 Jan 2013 22:58:17 +1100, Lie Ryan <lie.1296@gmail.com> >> Which is the same restriction as when using XML/JSON. What it means by >> locking the entire database is that an sqlite database can only be >> read/written by a single program at any moment in time. For batch > > Actually, SQLite3 will happily permit multiple readers (or did, the > newest version may have a new locking scheme). However, the first > connection that seeks to write will block as long as open readers are > active, yet will also block /new/ readers. When the open readers close, > the write can complete, and then new readers can enter. Conclusion: > ensure that even read-only operations have a "commit" operation to close > them You're correct. For more precise description of what sqlite can or cannot do with respect to concurrency, see http://www.sqlite.org/faq.html#q5. As far as I know, dbm does not support concurrencies at all, and neither does xml unless you put a lot of efforts into implementing your own file locking and all.
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Vote tallying... Lie Ryan <lie.1296@gmail.com> - 2013-01-20 12:15 +1100
csiph-web