You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2010/03/16 13:39:27 UTC

[jira] Updated: (DERBY-2017) Client driver can insert and commit partial data when a LOB stream throws IOException or does not match the specified length

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

Kristian Waagan updated DERBY-2017:
-----------------------------------

    Attachment: derby-2017-stream_status_preview.diff

Attaching a preview patch, where a Derby specific trailing status flag is sent as the last byte. The status flag is appended to the user data.
I think this solution is the simplest approach, and it should also be easy to deal with the compatibility issue. The status flag is stripped away, it isn't saved to disk.

The idea is to make the statement fail on the server side, and let the embedded driver deal with the clean-up. The error will then be reported to the client driver as any other error that may occur during statement execution.
In the case of multiple stream sources and an error in the first one, I figured it is easier to continue with the statement execution rather than to abort early on. This is because one would otherwise need recovery logic in both the client driver and the network server. As a possible optimization I thought of adding a status called STREAM_SKIPPED. This, possibly together with a single "fake" data byte, will be sent to the server for any remaining data sources. Doing this avoids having to read and send potentially large values when we know that the statement will fail.

The various statuses are modeled after the current code in the client code. We don't need all of them (we really only need SUCCESS and FAILURE), but maybe they can be helpful for debugging? Having many status values doesn't add overhead to the network protocol (we always send one byte).
Here's the current list:
  STREAM_OK
  STREAM_UNKNOWN_LENGTH  (used with layer-B streaming and in an assert)
  STREAM_READ_ERROR
  STREAM_READ_ERROR_ON_LEN_VAL
  STREAM_TOO_SHORT
  STREAM_TOO_LONG
  STREAM_SKIPPED

I'm considering removing at least STREAM_UNKNOWN_LENGTH and STREAM_READ_ERROR_ON_LEN_VAL (effectively merging them with STREAM_OK and  STREAM_READ_ERROR, respectively).

Remaining work on the patch:
  o layer-B streaming code
  o encryption code [1]
  o error handling on the client (I don't think we need to use the accumulated error mechanism when sending the status byte)

I'll continue work on finalizing the patch, but feel free to ask questions and comment on the proposed approach.


[1] We are currently materializing the value here, and I won't improve this as part of this issue.

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