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

• Key: DERBY-17
• Type: Bug
• Status: Resolved
• Resolution: Won't Fix
• Priority: Minor
• Assignee: Unassigned
• Reporter: Ramandeep Kaur
• Component/s: Network Server
• Affects Version/s: 10.0.2.0

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.

Comments

[Kathey Marsden]

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

[David Van Couvering]

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.

[Kathey Marsden]

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

[David Van Couvering]

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.

[Kathey Marsden]

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.