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