Re: Suspending SELECTs

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com>
Cc: "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Suspending SELECTs
Date: 2006-01-17 20:58:28
Message-ID: 20060117205828.GE17896@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Jan 17, 2006 at 09:06:53PM +0100, Alessandro Baretta wrote:
> Craig A. James wrote:
> >
> >Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-01-17 21:01:33 Re: wildcard search performance with "like"
Previous Message Jim C. Nasby 2006-01-17 20:40:44 Re: Ensuring data integrity with fsync=off