Skip to content

[CBRD-26961] Add client->server stream transport protocol (COPY first consumer) - #76

Draft
hgryoo wants to merge 4 commits into
CUBRID:developfrom
hgryoo:feature/stream_transport
Draft

[CBRD-26961] Add client->server stream transport protocol (COPY first consumer)#76
hgryoo wants to merge 4 commits into
CUBRID:developfrom
hgryoo:feature/stream_transport

Conversation

@hgryoo

@hgryoo hgryoo commented Jun 23, 2026

Copy link
Copy Markdown
Member

http://jira.cubrid.org/browse/CBRD-26961

Purpose

Add JDBC support for the shared client→server byte-stream transport introduced
in [CBRD-26961]. Its first consumer is COPY <table> FROM STDIN; the transport is
consumer-agnostic so later consumers (internal-LOB input) reuse the same wire path.
JDBC had no COPY/stream support, so this is net-new.

Implementation

  • UFunctionCode: STREAM_SEND_DATA(45) / STREAM_END(46), matching the server
    and CCI wire ordinals (after SET_CAS_CHANGE_MODE(44)).
  • UConnection: streamSendData(byte[], int, int) / streamEnd() jci request
    methods, modeled on lobWrite(). streamEnd() returns the number of rows loaded.
  • CUBRIDConnection (public API): streamData(byte[]) / streamData(byte[], int, int)
    and streamEnd(). After executing COPY ... FROM STDIN, send the encoded payload
    with streamData() and finish with streamEnd().

Usage

CUBRIDConnection con = ...;
con.createStatement().execute("COPY t FROM STDIN WITH (FORMAT BINARY)");
con.streamData(encodedRows);   // repeat as needed
int rows = con.streamEnd();

Remarks

Add JDBC support for the shared client->server byte-stream transport used by
COPY <table> FROM STDIN (and future internal-LOB input).

- UFunctionCode: STREAM_SEND_DATA(45) / STREAM_END(46), matching the server and
  CCI wire ordinals (after SET_CAS_CHANGE_MODE(44)).
- UConnection.streamSendData() / streamEnd(): jci request methods modeled on
  lobWrite(); streamEnd() returns the number of rows loaded.
- CUBRIDConnection.streamData() / streamEnd(): public API. After executing
  COPY ... FROM STDIN, send the encoded payload with streamData(byte[]) and
  finish with streamEnd().

Pairs in lockstep with the server (CBRD-26961) and CCI stream transport PRs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@hgryoo hgryoo self-assigned this Jun 23, 2026
hgryoo and others added 2 commits June 23, 2026 17:42
write(byte[], off, len) copied one byte at a time through write(int), with a
per-byte bounds/segment check. Replace the loop with System.arraycopy bounded
by the 100KB segment boundary. Output is byte-identical (same segmentation,
same dataSize); only the copy is bulk.

Micro-bench: ~1,400 MB/s -> ~5,500 MB/s steady (22 GB/s hot). Helps every bulk
send (COPY stream chunks, lobWrite, large parameters). COPY end-to-end gain is
small (server-bound), but the path is no longer byte-at-a-time.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hgryoo added a commit to hgryoo/cubrid that referenced this pull request Jun 23, 2026
…r e2e testing

Bump the submodule pointers so the engine PR (CUBRID#7343) bundles the matching
client-side stream transport code, letting others build/test COPY and the
stream transport end-to-end from a recursive clone:

  cubrid-cci  -> c2f9533 (CUBRID/cubrid-cci#105,  feature/stream_transport)
  cubrid-jdbc -> 094128f (CUBRID/cubrid-jdbc#76,  feature/stream_transport)

Both commits are fetchable by SHA from the base submodule URLs, so CircleCI
and recursive clones can check them out.

TEMPORARY -- for testing only. Restore both to develop SHAs before merge:
merge CUBRID#105 / CUBRID#76 first, bump the engine submodule to the new develop SHAs,
then merge CUBRID#7343. Otherwise mainline develop would reference commits that
are not on the clients' develop.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant