db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@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
Date Tue, 23 Feb 2010 14:58:28 GMT

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


Mime
View raw message