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;