Re: [pysqlite] database locked

Dennis Lee Bieber wrote:
> On Sun, 01 Jun 2008 11:21:17 -0400, "Eric S. Johansson"
> <[email protected]> declaimed the following in
> gmane.comp.python.db.pysqlite.user:
> 
> 	Warning: long response but short on exposition
>>   okay, this confuses me. I would think you would want to commit only after 
>> update or insert
>>
> 	Until you perform the commit/rollback, you will have a shared-read
> lock on the database; until all shared-read locks go away, no other
> process will be able to actually commit updates.

  this implies them that every select should be followed by a commit in order to 
release the shared read lock.  but...

> 	Same, except I fetch all data before attempting the commit...
> Interesting -- appears pysqlite2 and/or SQLite is "committing" the
> select once all the data has been fetched. So a .fetchall() may be
> sufficient, without needing an explicit .commit()

...if I remember, pysqlite does a bunch of autocommits.If memory serves, when I 
was first learning pysqlite, I was told one of the traps was the autocommit 
feature and sometimes turning it off was a good idea.

I can see why it took me so long to hit this problem.  Most of my data access, 
on a per record basis,  is performed in a single process.  There is very little 
opportunity for overlapping access in this particular database and but in 
another one, there will be significant opportunity.

I noticed you using execute many.  Is there a significant performance advantage 
to doing so?  I have one place where I process anywhere from 20 to a thousand 
records at a shot.   It may be worth writing some special case code for updating 
these records if there is.