Derby
  1. Derby
  2. DERBY-17

Network Server Needs to generate CRRTKN on ACCRDB if client does not send it

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 10.0.2.0
    • Fix Version/s: None
    • Component/s: Network Server
    • Labels:
      None

      Description

      Opening this bug on behalf of Katherine Marsden

      --------------------------------------------------------------
      JCC cannot guarantee that the CRRTKN that they send is unique
      because it may come from many jvms.

      According to the DDM Spec in ACCRDBRM we should generate and
      send CRRTKN if it was not sent to us.

      crrtkn INSTANCE_OF CRRTKN - Correlation Token
      1810 OPTIONAL
      1811 DFTVAL â??â??
      1812 NOTE Source server product-specific value is used.
      1813 This parameter is returned if and only if the
      1814 CRRTKN parameter is not received on
      1815 ACCRDB.

        Issue Links

          Activity

          Hide
          Kathey Marsden added a comment -

          See the specifications at:
          http://www.opengroup.org/dbiop/
          In particular, section 11.3.1 of:
          http://www.opengroup.org/onlinepubs/9699959699/toc.pdf
          for an explanation of the correlation token.

          and the ACCCRDB and ACCRDBRM definition in
          http://www.opengroup.org/onlinepubs/9699959499/toc.pdf

          The client would also need to be changed to not send the correlation token on ACCRDB

          Show
          Kathey Marsden added a comment - See the specifications at: http://www.opengroup.org/dbiop/ In particular, section 11.3.1 of: http://www.opengroup.org/onlinepubs/9699959699/toc.pdf for an explanation of the correlation token. and the ACCCRDB and ACCRDBRM definition in http://www.opengroup.org/onlinepubs/9699959499/toc.pdf The client would also need to be changed to not send the correlation token on ACCRDB
          Hide
          David Van Couvering added a comment -

          I'd like to understand why JCC cannot guarantee uniqueness. Reading the spec, the CRRTKN is a combination of the specific host and port of the client and a long value of the current timestamp, and that's how it's implemented in the client code (although for some reason I don't fully fathom it only uses half of the bytes of each part of the IP address). Since each client uses a different TPC-IP port, this value should be unique, even across VMs where the timestamp might match. The timestamp is just intended to guarantee uniqueness within the same VM.

          That said, if the CRRTKN is null, yes, according to the spec the network server should generate it. But unless I can understand how the CRRTKN generated by the client is not unique across VMs, I don't think it makes sense for the client to stop generating the CRRTKN.

          Show
          David Van Couvering added a comment - I'd like to understand why JCC cannot guarantee uniqueness. Reading the spec, the CRRTKN is a combination of the specific host and port of the client and a long value of the current timestamp, and that's how it's implemented in the client code (although for some reason I don't fully fathom it only uses half of the bytes of each part of the IP address). Since each client uses a different TPC-IP port, this value should be unique, even across VMs where the timestamp might match. The timestamp is just intended to guarantee uniqueness within the same VM. That said, if the CRRTKN is null, yes, according to the spec the network server should generate it. But unless I can understand how the CRRTKN generated by the client is not unique across VMs, I don't think it makes sense for the client to stop generating the CRRTKN.
          Hide
          Kathey Marsden added a comment -

          As I understand it, if there are multiple clients on the same machine there can be duplicates.

          Show
          Kathey Marsden added a comment - As I understand it, if there are multiple clients on the same machine there can be duplicates.
          Hide
          David Van Couvering added a comment -

          OK. I thought each connection to the server got a different port number, so since you are using local host and port as part of the CRRTKN it should be unique for each connection to the server. But what I'll do is just test this out.

          Show
          David Van Couvering added a comment - OK. I thought each connection to the server got a different port number, so since you are using local host and port as part of the CRRTKN it should be unique for each connection to the server. But what I'll do is just test this out.
          Hide
          Kathey Marsden added a comment -

          There doesn't seem to be much interest in fixing this issue and no problems seen with clients generating duplicate correlation tokens. From David's analysis, they should be unique. The issue can be reopened if someone decides to fix.

          Show
          Kathey Marsden added a comment - There doesn't seem to be much interest in fixing this issue and no problems seen with clients generating duplicate correlation tokens. From David's analysis, they should be unique. The issue can be reopened if someone decides to fix.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ramandeep Kaur
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development