Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #37101 > unrolled thread

Re: Vote tallying...

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Vote tallying... Lie Ryan <lie.1296@gmail.com> - 2013-01-20 12:15 +1100

#37101 — Re: Vote tallying...

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.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web