db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen <Oystein.Grov...@Sun.COM>
Subject Re: SQLTransientConnectionException with BLOB reads
Date Sat, 18 Aug 2007 15:27:39 GMT
Arthur Blake wrote:
> Yes, that was the problem.
> If I change my code to keep the Connection open after I have a Blob in 
> hand, and then read the Blob it works.
> It appears that also the ResultSet and PreparedStatement I used to fetch 
> the Blob must also remain open until I'm done reading the Blob.

Generally, you should be able to close result sets and statements and 
still be able to access the Blob.  However, if you run with autocommit 
on (default), closing a result set may commit the transaction, and Blobs 
may not be accessed after the transaction has been committed.

> That seems reasonable.
> Sorry that I didn't see that in the release notes (they are quite big) 
> as I didn't even realize I was doing this in the code... (my Lob reading 
> code was buried in some utility classes.)
> I believe the Release note entry for this is DERBY-2729 .
> Paraphrasing:  "Now Blobs and Clobs store their data in temporary files..."
> Can I assume that Blob reads (especially for smaller Blobs) will be 
> slower now because they will have to be copied to temp files?

The temporary files will only be created if you use the JDBC Blob 
methods to change the content of a blob (e.g., setBytes).  For the 
embedded driver, these methods were added in 10.3.  For methods existing 
in 10.2, I do not think the performance has changed much.  (For the 
client driver, we have switched to a locator-based inmplementation and 
some operations should be much faster, while a few will be probably be 
slightly slower.)


View raw message