> Hi all,
>
[quoted text clipped - 9 lines]
> iterate over the result set with next(). Has anyone encountered a
> similar problem? If so, how did you work around it?
Do you have auto-commit turned off?
I would think that BLOBs are retrieved in chunks by JDBC/CLI, and that in
between the retrieval of the chunks an implicit commit is run.

Signature
Knut Stolze
Information Integration Development
IBM Germany / University of Jena
skykeys - 29 Jun 2005 21:12 GMT
> > Hi all,
> >
[quoted text clipped - 11 lines]
>
> Do you have auto-commit turned off?
No, I did not. But I will try it now.
> I would think that BLOBs are retrieved in chunks by JDBC/CLI, and that in
> between the retrieval of the chunks an implicit commit is run.
Yes, this makes sense to me too. I'll keep you posted. Thanks for the
reply.
> --
> Knut Stolze
> Information Integration Development
> IBM Germany / University of Jena
skykeys - 29 Jun 2005 21:48 GMT
Thanks, Knut. After setting Connection.autoCommit(false), the
exception has gone away but (I believe) the result set is still closed
since ResultSet.next() returns "false" for the offending rows. If it
helps, I'm using the type 4 driver (db2jcc.jar and
db2jcc_license_cu.jar) in Tomcat.
Perhaps this is a character set issue? Hmmm. I've got one more thing
to try...hold on.
No, this is not a character set issue. In trying to isolate the
problem, I've written a small command line program to load the driver,
instantiate a connection, and select Blob content from the offending
columns and it works!
However, the same code executed in a servlet container yields closed
result sets. Perhaps this is a threading or security manager issue?
Until now, I thought DB2 Connection objects were threadsafe. Usually,
I instantiate one connection per servlet context and bind it to each
session in an HttpSessionListener. I may have to rethink this
approach.
If this is a security manager issue, then I'll have to devise a test
for that. I'll continue to investigate and keep you posted.
Thanks again!