Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 66252 invoked from network); 5 Dec 2006 07:04:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Dec 2006 07:04:12 -0000 Received: (qmail 23302 invoked by uid 500); 5 Dec 2006 07:04:20 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 23272 invoked by uid 500); 5 Dec 2006 07:04:20 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 23263 invoked by uid 99); 5 Dec 2006 07:04:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Dec 2006 23:04:20 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [192.18.19.10] (HELO sineb-mail-3.sun.com) (192.18.19.10) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Dec 2006 23:04:08 -0800 Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB573jeL009679 for ; Tue, 5 Dec 2006 15:03:46 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J9S00G01GSSLC00@mail-apac.sun.com> (original mail from Saurabh.Vyas@Sun.COM) for derby-dev@db.apache.org; Tue, 05 Dec 2006 15:03:45 +0800 (SGT) Received: from [129.158.251.104] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J9S00GQUGXXR9WQ@mail-apac.sun.com> for derby-dev@db.apache.org; Tue, 05 Dec 2006 15:03:33 +0800 (SGT) Date: Tue, 05 Dec 2006 12:33:32 +0530 From: Saurabh Vyas Subject: Require help in DRDA/DSS implementation (DERBY-2017) Sender: Saurabh.Vyas@Sun.COM To: derby-dev@db.apache.org Message-id: <457519C4.80609@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y5zv9o0/6tUAwLloDa4L2w)" User-Agent: Mail/News 1.5.0.4 (X11/20060718) X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --Boundary_(ID_y5zv9o0/6tUAwLloDa4L2w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi All, I was looking into Derby-2017 (https://issues.apache.org/jira/browse/DERBY-2017) the following were my findings : - when error occurs, then a dummyDSS is built and the partial data (which is *'this' *in the repro ) is sent across to NetworkServer. Now when the next select statement is executed, it commits the transaction and the partial data gets committed and select returns the incorrect committed data. - I modified the repro to rollback the transaction when error occurs, then it behaves correctly. code snippet.................... StringReader reader = new StringReader("this string is way too long"); ps.setCharacterStream(1, reader, 5); try { ps.executeUpdate(); } catch (SQLException e) { *c.rollback(); //see here* System.out.println(e); } --------------------------------------------------- - DRDA Header specifications provides a flag which can notify that error had occurred & do not continue. /** * Read DSS header * DSS Header format is * 2 bytes - length * 1 byte - 'D0' - indicates DDM data * 1 byte - DSS format * |---|---------|----------| * | 0 | flags | type | * |---|---------|----------| * | 0 | 1 2 3 | 4 5 6 7 | * |---|---------|----------| * bit 0 - '0' * bit 1 - '0' - unchained, '1' - chained * *bit 2 - '0' - do not continue on error, '1' - continue on error //See Here* * bit 3 - '0' - next DSS has different correlator, '1' - next DSS has * same correlator .......... */ - What I observed is, when error occurs (i.e. accumulateReadError) and writeCommitSubstitute is called where a dummy DSS is built (buildDummyEXCSAT()). - buildDss() method write the header information and here we should set the CONTINUE_ON_ERROR flag to '0' thus the data shold not be send to NetworkServer. Is my understanding correct? I am new to this part of derby and not familiar with the DRDA implementation. Comments/Suggestions please. I tried to follow Army's work on DERBY-35, but that is much target for chaining and I am not aware about Tomohito 's work in Layer B streaming. Can anyone help me out in this. Thanks, Saurabh --Boundary_(ID_y5zv9o0/6tUAwLloDa4L2w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi All,

I was looking into Derby-2017 (https://issues.apache.org/jira/browse/DERBY-2017) the following were my findings :
- when error occurs, then a dummyDSS is built and the partial data (which is 'this' in the repro ) is sent across to NetworkServer. Now when the next select statement is executed, it commits the transaction and the partial data gets committed and select returns the incorrect committed data.

- I modified the repro to rollback the transaction when error occurs, then it behaves correctly.

code snippet....................

        StringReader reader = new StringReader("this string is way too long");
        ps.setCharacterStream(1, reader, 5);

        try {
            ps.executeUpdate();
        } catch (SQLException e) {
            c.rollback(); //see here
            System.out.println(e);
        }
---------------------------------------------------

- DRDA Header specifications provides a flag which can notify that error had occurred & do not continue.

/**
     * Read DSS header
     * DSS Header format is
     *     2 bytes    - length
     *    1 byte    - 'D0'    - indicates DDM data
     *     1 byte    - DSS format
     *        |---|---------|----------|
     *        | 0    |  flags  |  type    |
     *        |---|---------|----------|
     *        | 0 | 1  2  3 | 4 5 6 7  |
     *        |---|---------|----------|
     *        bit 0 - '0'
     *        bit 1 - '0' - unchained, '1' - chained
     *        bit 2 - '0'    - do not continue on error, '1' - continue on error      //See Here
     *        bit 3 - '0' - next DSS has different correlator, '1' - next DSS has
     *                        same correlator
..........
*/

- What I observed is, when error occurs (i.e. accumulateReadError) and writeCommitSubstitute is called where a dummy DSS is built (buildDummyEXCSAT()).
- buildDss() method write the header information and here we should set the CONTINUE_ON_ERROR flag to '0' thus the data shold not be send to NetworkServer.
Is my understanding correct? I am new to this part of derby and not familiar with the DRDA implementation.
Comments/Suggestions please.

I tried to follow Army's work on DERBY-35, but that is much target for chaining and I am not aware about Tomohito 's work in Layer B streaming. Can anyone help me out in this.

Thanks,
Saurabh
--Boundary_(ID_y5zv9o0/6tUAwLloDa4L2w)--