From: Jim C. Nasby <jnasby@pervasive.com>
To: Alessandro Baretta <a.baretta@barettadeit.com>
Cc: Craig A. James <cjames@modgraph-usa.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Suspending SELECTs
Date: Tue, 17 Jan 2006 14:58:28 -0600
Message-ID: <20060117205828.GE17896@pervasive.com> (raw)
In-Reply-To: <43CD4E5D.7060406@barettadeit.com>
References: <43CB71AC.20203@barettadeit.com>
<9766.1137433907@sss.pgh.pa.us>
<43CC0DDF.9080904@modgraph-usa.com>
<43CD4E5D.7060406@barettadeit.com>
On Tue, Jan 17, 2006 at 09:06:53PM +0100, Alessandro Baretta wrote:
> Craig A. James wrote:
> >
> >Alessandro Baretta <a.baretta@barettadeit.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jnasby@pervasive.com, a.baretta@barettadeit.com, cjames@modgraph-usa.com
Subject: Re: Suspending SELECTs
In-Reply-To: <20060117205828.GE17896@pervasive.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox