X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id EEFCE9DC9AB for ; Tue, 17 Jan 2006 16:58:28 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14834-01 for ; Tue, 17 Jan 2006 16:58:29 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 8B8B29DC98B for ; Tue, 17 Jan 2006 16:58:26 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 0D09739830; Tue, 17 Jan 2006 14:58:28 -0600 (CST) Date: Tue, 17 Jan 2006 14:58:28 -0600 From: "Jim C. Nasby" To: Alessandro Baretta Cc: "Craig A. James" , pgsql-performance@postgresql.org Subject: Re: Suspending SELECTs Message-ID: <20060117205828.GE17896@pervasive.com> References: <43CB71AC.20203@barettadeit.com> <9766.1137433907@sss.pgh.pa.us> <43CC0DDF.9080904@modgraph-usa.com> <43CD4E5D.7060406@barettadeit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43CD4E5D.7060406@barettadeit.com> X-Operating-System: FreeBSD 6.0-RELEASE amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.093 required=5 tests=[AWL=0.093] X-Spam-Score: 0.093 X-Spam-Level: X-Archive-Number: 200601/263 X-Sequence-Number: 16741 On Tue, Jan 17, 2006 at 09:06:53PM +0100, Alessandro Baretta wrote: > Craig A. James wrote: > > > >Alessandro Baretta writes: > > > >I think you're trying to do something at the wrong layer of your > >architecture. This task normally goes in your middleware layer, not > >your database layer. > > I am developing my applications in Objective Caml, and I have written the > middleware layer myself. I could easily implement a cursor-pooling > strategy, but there is no perfect solution to the problem of guaranteeing > that cursors be closed. Remember that web applications require the user to > "open a session" by connecting the appropriate HTTP resource, but users as > never required to log out. Hence, in order to eventually reclaim all > cursors, I must use magical "log-out detection" algorithm, which is usually > implemented with a simple timeout. This guarantees the required property of > safety (the population of cursors does not diverge) but does not guarantee > the required property of liveness (a user connecting to the application, > who has opened a session but has not logged out, and thus possesses a > session token, should have access the execution context identified by his > token). With some "AJAX magic", it would probably be pretty easy to create an application that let you know very quickly if a user left the application (ie: browsed to another site, or closed the browser). Essentially, you should be able to set it up so that it will ping the application server fairly frequently (like every 10 seconds), so you could drastically reduce the timeout interval. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461