...

Motivation

When processing data, the user wants to have access to client attributes - an associative array specified on the client application side. Usage scenarios:

...

A similar context mechanism exists in Oracle [1].

Description

Accessing attributes

Code running on the Ignite node has access to client attributes through a static method call:

...

SessionContext can be further extended to retrieve other non-tabular information, such as SecuritySubject, Transaction, ServiceCallContext, etc.

Setting attributes

JDBC

The standard jdbc protocol describes the methods Connection#setClientInfo, which allow changing the values ​​of client attributes during the life of the connection [3]. Implementation features:

...

// JDBC connection to Ignite server.
try (Connection conn = DriverManager.getConnection(URL)) {
    conn.setClientInfo("SESSION_ID", "1234");
 
    ...
}

IgniteClient (Java)

Implementation features:

1. The Java implementation of the thin client allows working in a multi-threaded environment, unlike the jdbc connection. It is suggested to bind the ClientAttributes setting to the current thread. In case of using listeners, it is necessary to reinstall the context in a new thread.
2. The parameters set via the withClientAttributes call are sent along with each outgoing TcpClientChannel#send message in the BinaryOutputStream (a new feature is needed in the ClientBitmaskFeature protocol).

...

try (IgniteClient cln = Ignition.startClient(clnCfg)) {
    try (ClientAttributes clnAttrs = cln.withClientAttributes()) {
        clnAttrs.setAttribute("SESSION_ID", "1234");
 
        ...
    }
}

Ignite 

The Ignite server node, when receiving client messages, sets ClientAttributes in the ThreadLocal variable, and also handles context transfer to the calls it spawns (in threads and on remote nodes). The same can be done for operations called directly from Ignite:

try (Ignite ign = Ignition.localIgnite()) {
    try (ClientAttributes clnAttrs = ign.withClientAttributes()) {
        clnAttrs.setAttribute("SESSION_ID", "1234");
 
        ...
    }
}

Spreading context across cluster nodes

1. Via the QueryStartRequest SQL message protocol.
2. Via the discovery protocol for handling inserts (CacheInterceptor), since inserts are not always performed on the request initiator node.
   1. GridNearAtomicAbstractUpdateRequest messages about key changes must contain the ClientAttributes id.
   2. Can only be sent if the SQL query has an insert (since CacheInterceptor#onGet is not called in SQL)
   3. It is necessary to clean up contexts on nodes (after completing queries, disconnecting clients, or changing ClientAttributes on the client)

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

Discussion Links

// Links to discussions on the devlist, if applicable.

Reference Links

// Links to various reference documents, if applicable.

Tickets

// Links or report with relevant JIRA tickets.