db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB
Date Fri, 25 Aug 2006 00:09:52 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1559?page=comments#action_12430363 ] 
            
Bryan Pendleton commented on DERBY-1559:
----------------------------------------

Thanks Andreas. I fear I was perhaps a little vague in my previous comment.

The code I was concerned about was the code in EXTDTAReaderInputStream.java that looks like:

 } catch (DRDAProtocolException e) {
            throw new IOException(e.getMessage());
 }

which is a pattern that occurs in several places in that class.

I was concerned that all the information we were extracting from the exception object "e"
was the getMessage() string, and were hence losing the stack trace of where exactly
the original DRDAProtocolException was thrown.

I was suggesting that we might change that code into:

 } catch (DRDAProtocolException e) {
            throw new IOException(e.getMessage(), e);
 }

so that exception 'e' would be recorded as the "cause" of the new IOException,
but this would require using the new JDK 1.4 version of the constructor, so
instead we might try to figure out some other way to capture the stack trace
information from the exception "e".

Does my comment make more sense now?

thanks,

bryan


> when receiving a single EXTDTA object representing a BLOB, the server do not need to
read it into memory before inserting it into the DB
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1559
>                 URL: http://issues.apache.org/jira/browse/DERBY-1559
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Network Server
>    Affects Versions: 10.2.1.0, 10.3.0.0, 10.2.2.0
>            Reporter: Andreas Korneliussen
>         Assigned To: Andreas Korneliussen
>         Attachments: DERBY-1559.diff, DERBY-1559.stat, DERBY-1559v2.diff, DERBY-1559v3.diff,
DERBY-1559v4.diff, serverMemoryUsage.xls
>
>
> When streaming a BLOB from the Network Client to the Network Server, the Network server
currently read all the data from the stream and put it into a byte array.
> The blob data is then inserted into the DB by using
> PreparedStatement.setBytes(..)
> and later
> PreparedStatement.execute()
> To avoid OutOfMemoryError if the size of the Blob is > than total memory in the VM,
we could make the network server create a stream which reads data when doing PreparedStatement.execute().
 The DB will then stream the BLOB data directly from the network inputstream into the disk.
> I intent to make a patch which does this if there is only one EXTDTA object (BLOB) sent
from the client in the statement, as it will simplify the implementation. Later this can be
improved  further to include CLOBs, and possibly to include the cases where there are multiple
EXTDTA objects.
> --
> CLOBs are more complex, as there need to be some character encoding. This can be achieved
by using a InputStreamReader,  and use PreparedStatement.setCharacterStream(..). However the
size of the stream is not necessarily the same as the size of the raw binary data, and to
do this for CLOBs, I would need the embedded prepared statements to support the new setCharacterStream()
overloads in JDBC4 (which do not include a length atribute)
> --
> Multiple EXTDATA objects are also more complex, since one would need to have fully read
the previous object ,before it is possible to read the next.
> --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message