Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'read-only': 0.07; 'closed.': 0.09; 'complicate': 0.09; 'newest': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:80.91.229.12': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'received:lo.gmane.org': 0.09; 'operations,': 0.15; '"frank': 0.16; '(read': 0.16; 'bieber': 0.16; 'cursor': 0.16; 'declaimed': 0.16; 'email addr:ix.netcom.com': 0.16; 'email name:wlfraed': 0.16; 'from:addr:ix.netcom.com': 0.16; 'from:addr:wlfraed': 0.16; 'from:name:dennis lee bieber': 0.16; 'received:66.245': 0.16; 'received:dsl.mindspring.com': 0.16; 'received:wlfraed': 0.16; 'sqlite3': 0.16; 'subject:iterable': 0.16; 'url:netcom': 0.16; 'url:wlfraed': 0.16; 'wulfraed': 0.16; 'commit': 0.21; 'subject:Question': 0.21; 'url:home': 0.21; 'correct,': 0.23; 'locking': 0.23; 'lee': 0.28; 'second': 0.29; 'problem': 0.29; '+0200,': 0.30; 'sun,': 0.30; 'nov': 0.31; 'version': 0.31; 'returning': 0.32; 'to:addr:python-list': 0.32; 'instead': 0.33; 'header:X-Complaints-To:1': 0.33; 'especially': 0.34; 'retain': 0.34; 'connection': 0.36; 'charset:us-ascii': 0.36; 'executing': 0.36; 'doing': 0.37; 'but': 0.37; 'received:org': 0.37; 'processing': 0.38; 'should': 0.39; 'pending': 0.39; 'subject:: ': 0.39; 'to:addr:python.org': 0.39; '2011': 0.62; 'readers': 0.71; 'connection,': 0.73; 'analysis': 0.75; 'dennis': 0.77 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Dennis Lee Bieber Subject: Re: Question about 'iterable cursors' Date: Sun, 06 Nov 2011 12:04:11 -0800 Organization: > Bestiaria Support Staff < References: <87pqh54nmh.fsf@dpt-info.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gmane-NNTP-Posting-Host: user-11fb5l5.dsl.mindspring.com X-Newsreader: Forte Agent 3.3/32.846 X-No-Archive: YES X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 26 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1320609864 news.xs4all.nl 6959 [2001:888:2000:d::a6]:49895 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:15388 On Sun, 6 Nov 2011 11:39:56 +0200, "Frank Millman" declaimed the following in gmane.comp.python.general: > > So my analysis of the problem is correct, but my solution is wrong. > > Instead of executing fetchall() and returning the connection, I should > retain the connection until I have exhausted the cursor. > > That makes a lot of sense. > Especially if all you are processing are read-only activities. If you have a connection/cursor doing write operations, you may not be able to commit those writes until all reading cursors have closed. (Read the documentation on the SQLite3 locking system -- though the newest version has added a second type of locking which may complicate the matter. The original/normal scheme has potential readers "outside" SQLite3, active readers "inside" SQLite3 -- when an active reader cursor advances to a pending write, it blocks all the potential readers from entering, but is itself blocked until all other active readers have exited) -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/