...

1. To run certain business logic that depends on the value of the current session attribute (for example, the application language [2]).
2. To audit changes in the database (for example, CacheInterceptor extracts the user from the attrubutes attributes and saves it along with the data).
3. To optimize the transfer of parameters to processing functions (for example, multiple QuerySqlFunction use the same parameter and it is convenient to take it from the attributes, rather than transfer it separately to each function).

...

1. The Java implementation of the thin client allows working in a multi-threaded environment, unlike the jdbc connection. It Then 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.transaction.
2. It's required to extend ClientTransactions interface with withClientAttributes method, similar to withLabel.
3. New 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(// Extends the interface with new public method.
public interface ClientTransactions {
	...

    /** @param clnAttrs Client attributes. */
    public ClientTransactions withClientAttributes(Map<String, String> clnAttrs);
}

// Example of usage.
try (IgniteClient cln = Ignition.startClient(clnCfg)) {
    Map<String, String> clnAttrs = clnAttrsF.setAttributeasMap("SESSION_ID", "1234");

    try (ClientTransaction tx = cln.transactions().withClientAttributes(clnAttrs).txStart()) {
        ...
    }
}

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 IgniteSame as IgniteClient - attach the attributes to transaction:

// Extends the interface with new public method.
public interface IgniteTransactions {
 	...

    /** @param clnAttrs Client attributes. */
    public IgniteTransactions withClientAttributes(Map<String, String> clnAttrs);
}

// Example of usage.
try (Ignite ign = Ignition.localIgnite()) {
     Map<String, String> clnAttrs = F.asMap("SESSION_ID", "1234");
 
     try (ClientAttributesTransaction clnAttrstx = ign.transactions().withClientAttributes(clnAttrs).txStart()) {
        clnAttrs.setAttribute("SESSION_ID", "1234");
 
        ...
    }
}

...

1. Via the QueryStartRequest SQL message protocol .(for jdbc)
2. Via the discovery transaction protocol for handling inserts (CacheInterceptor), since inserts are not always performed on the request initiator node.GridNearAtomicAbstractUpdateRequest messages about key changes must contain the ClientAttributes id.
3. Can only be sent if the SQL query has an insert (since CacheInterceptor#onGet is not called in SQL)
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.

...