> To: Kovács Péter
> Cc: [EMAIL PROTECTED]
> Subject: Re: [JDBC] JDBC 2 ResultSet and cursors
>
>
> Right, but a single Connection should be able to be used
> concurently. For example if you
> were writing a servlet that handled incoming requests by doing:
> Statement s
Right, but a single Connection should be able to be used concurently. For example if
you
were writing a servlet that handled incoming requests by doing:
Statement s = myconnection.createStatement();
ResultSet rs = s.doQuery();
//use rs here
You can't tie up the entire connection until the resu
What do you mean by a connection being shared? What connection is shared
by/between whom? My understanding is that "physical" connections (at least
in the current jdbc driver coming with PostgreSQL) are NOT shared between
java.sql.Connection instances. (Each java.sql.Connection instance has the
ex
To use a cursor behind the scenes would require the jdbc driver to have its own
begin/end
block. Because the connection is shared, there is nothing that prevents someone else
from
trying to execute a begin/end/commit/rollback statement that would screw up the
driver.
So it would need a sepe
I am afraid I do not understand your explanation. What do you mean by
"begin/end block"? I am thinking in terms of simple SQL statements like:
begin;
declare myc cursor for select * from mm_history;
fetch forward 2 in myc;
close myc;
rollback; (or if you did some update in the same transaction: c
Because the driver would have to dedicate a connection to the backend to the resultset
to
make sure nobody else tries to begin/end a block while it is trying to use a cursor.
(that's the simple explanation) Since a connection to the backend currently requires
a
fork, it would be a real resou
Hi Peter
> Why the scrollable result sets are not implemented in the current jdbc
> driver? Is it technically impossible or just no one needed this feature yet?
As far as I know the read-only result sets are working in the recent drivers.
for instance
Statement stm = con.createStatement(ResultS
