Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <493829960.462931266937108084.JavaMail.jira@brutus.apache.org>
Date: Tue, 23 Feb 2010 14:58:28 +0000 (UTC)
From: "Kristian Waagan (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&focusedCommentId=12837265#action_12837265 ] 

Kristian Waagan commented on DERBY-2017:
----------------------------------------

Hi Rick,

I agree that in the general case there might be race conditions, but that shouldn't be a problem in this specific case. To cancel truly running requests I understand that a second connection is needed, since the existing one is stuck waiting for the server reply.
I think we can control when the statement completes, since we are controlling when we send data to the server. Be holding back data, the server thread will be stuck.

However, when prototyping this, it seems to me that the complexity of this approach is a lot higher than adding a product specific code point.
We would need to handle the following issues:
 - creating a new connection based on an existing connection. Here we would need to have things like the user name and password available.
 - introducing an interrupt token (sent to the client on ACCRDB, sent back to the server to identify which session to interrupt)
 - looking up session based on interrupt token on the server side
 - interrupt logic on the server side

We might get away with one thread on the client side, but on the server side we need two threads / connections to communicate with each other. The overall process would be something like this (there are several variations):
 - client sends data
 - client detects problem (too much data or too little data)
 - client creates a second connection (the server session is currently stuck in a read loop awaiting more data, or maybe the last piece of data)
 - the second thread on the server (new connection) signals that a DRDA interrupt has been requested
 - the client sends valid data (wrt the DRDA protocol) to the server session to wake it up
 - the server reads data, detects interrupt request and aborts the current statement
 - the second thread on the server sends a reply to the interrupt request itself
 - the client reads the reply (second connection)
 - the first server thread informs that the running request was interrupted and canceled
 - the client reads reply from the original connection and throws exception

In addition to the code complexity, we must also make sure we obey the DRDA protocol rules to avoid network protocol errors.


As a side note, the code in org.apache.derby.impl.drda.DRDAConnThread.convertAsByteArrayInputStream can cause OOME on the server for if more than one large LOB is transferred from the client in the same statement. 


> 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
>         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.