db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)
Date Thu, 13 Jul 2006 23:35:15 GMT
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).  This is something that could be caught the next 
time the am code hits the network layer for something.  The network 
layer would notice there was a half-processed BLOB and Do The Right Thing.

Lots of hand-waving, but it seems to me that this is solvable, and it 
seems quite problematic to me that as it stands we just shoot the user 
in the foot if they happen to have a BLOB column that's larger than 
available memory, and there's nothing they can do to mitigate that.

David


Bryan Pendleton wrote:
> David Van Couvering wrote:
>> ... We should not allow any other requests to be sent to the server 
>> over this connection until the BLOB data is processed or cancelled 
> 
> I'm not quite sure how we would do this. What is preventing the client 
> from,
> say, calling ResultSet.next(), or going off to some other Statement object
> and running some other query, etc.?
> 
> The DRDA protocol has a whole lot of logic regarding exactly how
> the requestor and the server communicate about the state of the 
> conversation,
> what statements are in play and how to request or respond with actions 
> on them,
> what results have already been communicated, how to pick up and resume a
> partially-fetched set of query results, etc.
> 
> DRDA may well have all the protocol mechanisms in place for suspending an
> externalized data object partway through, picking it up later, etc., and we
> may already have all that support in place in our network client libraries.
> 
> But I think there's some DRDA research waiting to be done here, that was 
> the
> main point I was trying to raise.
> 
> thanks,
> 
> bryan
> 
> 

Mime
View raw message