Re: jdbc: getBinaryStream blocks on second call

Lists: pgsql-interfaces
From: Ingo Luetkebohle <ingo(at)blank(dot)pages(dot)de>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: jdbc: getBinaryStream blocks on second call
Date: 2000-12-03 16:13:02
Message-ID: 20001203171302.B1619@blank.pages.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-interfaces

Hello,

I'm using the Postgresql-JDBC interface inside of a Jave Server Page
and request a large object. When the page is first called, it works
fine. When its called twice for the same database row, the
ResultSet.getBinaryStream method blocks infinetely. This is on
postgresql 7.0.3 (from RPM, on Linux, glibc).

The code is something like:

dbc.setAutoCommit(false);
Statement st = dbc.createStatement();
ResultSet rs = st.executeQuery("SELECT contents FROM file WHERE id=" + id);
dbc.commit();
if(rs.next()) {
Reader r = new InputStreamReader(rs.getBinaryStream(1));
char buf[] = new char[2048];
for(int read = r.read(buf); read != -1; read = r.read(buf))
out.write(buf, 0, read);

out.flush();
r.close();
is.close();
}

(yes, I known that the getBytes method is more convenient but the
JspWriter class a JSP page provides can't write byte[], only char[])

--
Ingo Luetkebohle / ingo(at)blank(dot)pages(dot)de / 95428014
/
|PraxisXML Open Source contact; Computational Linguistics
|student; Fargonauten.DE sysadmin; Gimp Registry (not-)maintainer;


From: Greg Speegle <Greg(at)10happythings(dot)com>
To: Ingo Luetkebohle <ingo(at)blank(dot)pages(dot)de>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: jdbc: getBinaryStream blocks on second call
Date: 2000-12-03 19:10:21
Message-ID: 3A2A9A9D.9000803@10happythings.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-interfaces


Within JDBC 1.0, it is required to access the columns in a result set
row from left to right
and only once. Since the Postgres JDBC driver is not totally 2.0, it's
not mandatory, but it
is a real good idea. I'd suggest storing the byte array somewhere so you
don't have to
read it twice. If you have to read it twice, the only way to gaurantee
that it works, is to
close the Statement and do it again.

Greg Speegle
Baylor University

Ingo Luetkebohle wrote:

> Hello,
>
> I'm using the Postgresql-JDBC interface inside of a Jave Server Page
> and request a large object. When the page is first called, it works
> fine. When its called twice for the same database row, the
> ResultSet.getBinaryStream method blocks infinetely. This is on
> postgresql 7.0.3 (from RPM, on Linux, glibc).
>
> The code is something like:
>
> dbc.setAutoCommit(false);
> Statement st = dbc.createStatement();
> ResultSet rs = st.executeQuery("SELECT contents FROM file WHERE id=" + id);
> dbc.commit();
> if(rs.next()) {
> Reader r = new InputStreamReader(rs.getBinaryStream(1));
> char buf[] = new char[2048];
> for(int read = r.read(buf); read != -1; read = r.read(buf))
> out.write(buf, 0, read);
>
> out.flush();
> r.close();
> is.close();
> }
>
> (yes, I known that the getBytes method is more convenient but the
> JspWriter class a JSP page provides can't write byte[], only char[])
>


From: Ingo Luetkebohle <ingo(at)blank(dot)pages(dot)de>
To: Greg Speegle <Greg(at)10happythings(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: jdbc: getBinaryStream blocks on second call
Date: 2000-12-03 21:33:04
Message-ID: 20001203223304.A20177@blank.pages.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-interfaces

On Sun, Dec 03, 2000 at 01:10:21PM -0600, Greg Speegle wrote:
> If you have to read it twice, the only way to gaurantee that it
> works, is to close the Statement and do it again.

Thanks for the tip, it led me in the right direction. Closing the
Statement didn't suffice, but closing the whole DB connection
worked. Not beautiful, but ok for the moment.

--
Ingo Luetkebohle / ingo(at)blank(dot)pages(dot)de / 95428014
/
|PraxisXML Open Source contact; Computational Linguistics
|student; Fargonauten.DE sysadmin; Gimp Registry (not-)maintainer;