Skip site navigation (1) Skip section navigation (2)

Re: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set

From: Dave Crooke <dcrooke(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, pgsql-jdbc(at)postgresql(dot)org, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
Date: 2010-04-20 15:47:25
Message-ID: w2kca24673e1004200847k77429a1cra0a6f3560d407d8e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbcpgsql-performance
AFAICT from the Java end, ResultSet.close() is supposed to be final. There
is no way I know of in JDBC to get a handle back to the cursor on the server
side once you have made this call - in fact, its sole purpose is to inform
the server in a timely fashion that this cursor is no longer required, since
the ResultSet itself is a Java object and thus subject to garbage collection
and finalizer hooks.

At a pragmatic level, the PGSQL JDBC driver has a lot of odd behaviours
which, while they may or may not be in strict compliance with the letter of
the standard, are very different from any other mainstream database that I
have accessed from Java .... what I'd consider as normative behaviour, using
regular JDBC calls without the need to jump through all these weird hoops,
is exhibited by all of the following: Oracle, SQL Server, DB2, MySQL, Apache
Derby and JET (MS-Access file-based back end, the .mdb format)

In practce, this places PGSQL as the odd one out, which is a bit of a
turn-off to expereinced Java people who are PG newbies for what is otherwise
an excellent database.

At my current post, I came into a shop that had PG as the only real
database, so I have learned to love it, and de-supported Derby and the other
toy back ends we used to use. And to be fair, from a back end perspective,
PG is better than MySQL in terms of manageability .... I am running 250GB
databases on small systems with no issues.

At my previous shop, we built a couple of database-backed apps from scratch,
and despite a desire to use PG due to there being more certainty over its
future licensing (it was just after Sun had bought MySQL AG), I ended up
switching from PG to MySQL 5.0.47 (last open source version) because of the
difficulties I was having with the PG driver.

I consider part of the acme of great FOSS is to make it easy to use for
newbies and thus attract a larger user base, but that is just my $0.02
worth.

Cheers
Dave

On Tue, Apr 20, 2010 at 9:28 AM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:

> Dave Crooke <dcrooke(at)gmail(dot)com> wrote:
>
> > I'd consider the fact that ResultSet.close() does not release the
> > implicit cursor to be something of a bug
>
> What's your reasoning on that?  The definitions of cursors in the
> spec, if memory serves, allow a cursor to be closed and re-opened;
> why would this be treated differently?
>
> -Kevin
>

In response to

Responses

pgsql-performance by date

Next:From: Kris JurkaDate: 2010-04-20 16:07:48
Subject: Re: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
Previous:From: Kevin GrittnerDate: 2010-04-20 14:28:15
Subject: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set

pgsql-jdbc by date

Next:From: Kris JurkaDate: 2010-04-20 16:07:48
Subject: Re: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
Previous:From: Kevin GrittnerDate: 2010-04-20 14:28:15
Subject: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group