Bryan Pendleton wrote:
> David Van Couvering wrote:
>> I guess what I was assuming was, if the application goes off and does
>> something else, we can notice that and either raise an exception
>> ("you're not done with that BLOB column yet") or flush the rest of the
>> BLOB data, since it's obvious they won't be getting back to it (e.g.
>> if they send another query or do ResultSet.next(), it's clear they're
>> done with the BLOB column).
>
> Are you sure that's acceptable JDBC behavior? My (very old) copy of the
> JDBC spec says things like:
>
> The standard behavior for a Blob instance is to remain valid until the
> transaction in which it was created is either committed or rolled back.
>
> So if I do something like:
>
> ResultSet rs = stmt.executeQuery("SELECT DATA FROM TABLE1");
> rs.first();
> Blob data = rs.getBlob("DATA");
> InputStream blobStream = blob.getBinaryStream();
>
> I think I am supposed to be allowed to access blobStream quite some time
> later,
> even if I do other things on the connection in the meantime.
>
There is a similar discussion in
http://www.nabble.com/-jira--Updated%3A-%28DERBY-721%29-State-of-InputStream-retrieved-from-resultset-is-not-clean-%2C-if-there-exists-previous-InputStream-.-tf664829.html#a1805521
I understand that to preserve a BLOB throughout the lifetime of the
transaction may be complicated.
I would suggest a simplification:
* We could optimize on the case where the user handles one column in the
row at the time. If the user moves away from the row, or to another
column, we could flush the Blob into memory, otherwise, if there is a
nice user who handles one row / one column at the time, the user will
avoid outofmemory issues. If there is a user who makes a tablescan and
collects all the n Blob objects in memory, the user may risk OutOfMemory
problems.
Additionally, I think we should be conservative and check available
memory before allocating memory for BLOBs, due to all the side-effects
to the applications when the VM goes out of memory.
Andreas