Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 44590 invoked from network); 15 Aug 2006 08:59:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Aug 2006 08:59:10 -0000 Received: (qmail 31687 invoked by uid 500); 15 Aug 2006 08:59:09 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 31473 invoked by uid 500); 15 Aug 2006 08:59:09 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 31464 invoked by uid 99); 15 Aug 2006 08:59:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2006 01:59:09 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2006 01:59:08 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4B6DA410021 for ; Tue, 15 Aug 2006 08:56:15 +0000 (GMT) Message-ID: <30981677.1155632175306.JavaMail.jira@brutus> Date: Tue, 15 Aug 2006 01:56:15 -0700 (PDT) From: "Andreas Korneliussen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (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 In-Reply-To: <13707545.1153483633946.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: ---------------------------------------- Attachment: DERBY-1559v2.diff Attached is an updated patch which preserves the changes in DERBY-1535 when receiving multiple EXTDTA objects. > 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.0.0 > Reporter: Andreas Korneliussen > Assigned To: Andreas Korneliussen > Attachments: DERBY-1559.diff, DERBY-1559.stat, DERBY-1559v2.diff > > > 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