[
https://issues.apache.org/jira/browse/DERBY-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849693#action_12849693
]
Kristian Waagan commented on DERBY-2017:
----------------------------------------
Description of patch 3a:
* iapi/reference/DRDAConstants
Constants for the various error conditions. There are currently four different
conditions: OK, READ_ERROR, TOO_SHORT and TOO_LONG.
Two would be enough, but having more may help debugging / tracing (from the
server side) and it doesn't add much complexity / overhead.
* drda/StandardEXTDTAReaderInputStream
Extended the stream reading "normal" EXTDTA to handle the Derby-specific status
byte.
See comment under drda/EXTDTAReaderInputStream.
* drda/LayerBStreamedEXTDTAReaderInputStream
Extended the stream reading layer B streamed EXTDTA to handle the
Derby-specific status byte.
Slightly more complex than the normal case, as we don't know up front when we
read the last data byte.
First I tried to make the stream check the status when it read the last byte,
but the code got too complex due to buffer boundary issues (i.e. I had to deal
with a "carry-over" byte etc). The stream now requires that it is properly
drained to guarantee that the status byte is read (i.e. read in a loop until
you get -1). This is the normal operational mode, so it shouldn't cause
problems.
To my knowledge this stream is always passed directly into the embedded driver,
which means it should thrown an exception instead of saving the status byte.
* drda/EXTDTAReaderInputStream
Extended the class to deal with the Derby-specific status byte.
Contains the logic determining if something went wrong when reading the stream
on the client side. If so, either an exception is thrown or the status if saved
for later inspection.
Seems I removed some required functionality here, as I think we have to be able
to explicitly tell if an error condition should cause an exception to be thrown
or not. The reason is that sometimes Derby reads the value off the network
before executing the statement. I want the statement itself to fail, as this
simplifies the clean-up and error handling.
* drda/FailingEXTDTAInputStream
Dummy stream that will throw an exception as soon as a read request is made.
* drda/AppRequester
Added method that tells if the client supports EXTDTA aborts or not.
* drda/DRDAConnThread
Fixed some suboptimal logic in convertAsByteArrayInputStream, where the buffer
size could be set to poorly chosen values (very small or too large).
In the case of normal EXTDTAs, added logic to pass in a stream that will fail
instead of the stream containing padded or truncated data.
* drda/DDMReader
Modified the code creating the streams reading data off the wire to tell
whether a Derby-specific status byte is expected or not.
* tests/jdbc4/PreparedStatementTest
Removed special code that was added due to DERBY-2017.
* client/net/NetDatabaseMetaData
Added code to tell if the server supports EXTDTA aborts.
* client/net/NetConnection
Added method calling code added in NetDatabaseMetaData.
* client/net/Request
The changes required to send the status byte (both for layer A and layer B
streaming).
Note that I suspect that the method writeEncryptedScalarStream is dead code.
There are several major problems with it, suggesting that it isn't used. I may
remove this code in a later patch, added a comment for now.
I'll add some more JavaDoc for some of the existing methods in Request, add
some tests for binary data (as opposed to character data) and verify that all
code paths in DRDAConnThread.readAndSetExtParam are covered.
> 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: Kristian Waagan
> Attachments: derby-2017-2a-regression_test.diff,
> derby-2017-2b-regression-test.diff, derby-2017-3a-fix.diff,
> derby-2017-3a-fix.stat, derby-2017-stream_status_preview.diff,
> 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.
