Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <15042469.1180956576293.JavaMail.jira@brutus>
Date: Mon, 4 Jun 2007 04:29:36 -0700 (PDT)
From: "V.Narayanan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2017) Client driver can insert and commit
 partial data when a LOB stream throws IOException or does not match the
 specified length
In-Reply-To: <18308033.1162198636492.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501179 ] 

V.Narayanan commented on DERBY-2017:
------------------------------------

Some thoughts on this issue.

The solution for this is difficult because of the following reason

The idea of not causing an OutOfMemory error in the client is that 
you should transmit the data without materializing it. 

But how would you get the length then? This would be necessary to
throw the stream truncation exception that is thrown.

I somehow feel that the trick of not writing this data should lie in the server
and the client rather than in the client alone.

a) The server should keep with it the data it gets from the stream sent as chunks
   without writing it into the database. 

b) When the client reaches the end of the stream it comes to know that the 
   truncation has happened it would inform the server that truncation has
   happened and the server does not write the data.

The above outlined steps would be possible if the PreparedStatement were
converted to use locators. So when a setBinaryStream is called

a) create a locator value

b) write the stream to the locator value(using CLOBSETSTRING or BLOBSETBYTES)

c) If truncation happens Call CLOBRELEASELOCATOR and release this value.
   Note: here we have not gone to the PreparedStatement execute as yet.

d) If there is not truncation do what happens in locators attach the stream
   to the PreparedStatement as happens for locators now.

Drawbacks
---------

1) This implementation would mean not using Layer-B streaming for Prepared Statements. 
   Layer-B streaming is a better way to transmit this stream data than locators
   which was the reason that during locator work the decision was taken to 
   retain Layer-B implementation here. See Derby-2529.

2) Locators involve building a temporary LOB on the server. This would again
   make it less efficient than Layer-B streaming.

> Client driver can insert and commit partial data when a LOB stream throws IOException or does not match the specified length
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2017
>                 URL: https://issues.apache.org/jira/browse/DERBY-2017
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.2.1.6
>            Reporter: Knut Anders Hatlen
>            Assignee: Mayuresh Nirhali
>         Attachments: derby2017_try1.diff, Derby_2017_v1.diff, Derby_2017_v1.stat, StreamErrRepro.java
>
>
> When a LOB stream throws an exception or does not match the specified length, the client driver does not raise an exception until it has finished executing the statement. Therefore, the statement will be executed (and possibly committed) on the server even though the client reports that the statement failed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.