ID	IEP-126
Author	Maksim Timonin
Sponsor
Created	10.09.2024
Status	DRAFT

Motivation

When processing data, users want to have access to non-tabular (not stored in cache structures) data.

Application attributes - an associative array specified on an application side. Business logic might depend on such attributes - application language, application name, date/time formats, debug tokens, etc ([2], [4]).
SecuritySubject can be used to provide fine-grained access control to cache data. For example, CacheInterceptor saves the subject id it along with data and it can be used for filtering.

The requirements include:

Data must be accessible from user defined functions (QuerySqlFunction, CacheInterceptor) on all nodes participated in queries.
Application attributes can change during the life of the connection (a connection from a connection pool can be sequentially used by different applications).

Ignite does not have a such API:

ServiceCallContext helps solve similar problems, but has several limitations - available only by calls via the IgniteService API and cannot be used for primitive operations.
UserAttributes - allows to set user attributes, but the attribute values are fixed for the entire lifetime of the connection.
ClientListenerConnectionContext - it's available only on single node which directly accepts a client connection.

Application context mechanism exists in Oracle [1] and it's widely used [6]. Support similar mechanisms (session variables) exist in multiple DBMS (e.g. SQLServer [8], Snowflake [7], MySQL [9]).

Description

Accessing attributes

ApplicationContext is an entrypoint for accessing all non-tabular data.
The access requires static methods, because objects injection isn't possible for user functions (QuerySqlFunction are static, CacheInterceptor is a cache singleton).
User can easily create own QuerySqlFunction to get access to the attribute from SQL if needed.

/** ApplicationContext interface. It's an entrypoint for all non-tabular data. */
public class ApplicationContext {
    /** @return Application attributes set for current thread. */
    public static @Nullable Map<String, String> getAttributes();

    /** @return Current SecuritySubject. */
	public static @Nullable SecuritySubject getSecuritySubject();
 }
 
/** Example, use it in QuerySqlFunction. */
public static class UserDefinedFunctions {
    /** @return Session ID set with application attributes. */
    @QuerySqlFunction
    public static @Nullable String sessionId() {
        Map<String, String> appAttrs = ApplicationContext.getAttributes();
 
        return appAttrs == null ? null : appAttr.get("SESSION_ID");
    }
}

Setting attributes

IgniteClient (Java)

Client should mirror the logic of Ignite node.
New feature is needed in the ClientBitmaskFeature protocol.

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

    try (ClientTransaction tx = cln.transactions().withApplicationAttributes(appAttrs).txStart()) {
        ...
    }
}

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:

The list of attributes that can be set using #setClientInfo is arbitrary. The documentation recommends strictly limiting the set of attributes, but this is not necessary. For example, Oracle does not have such a limitation [5]. The setClientInfo array is completely translated into the getClientAttributes array.
The parameters set in setClientInfo are passed along with each JdbcRequest (this requires a new feature in JdbcThinFeature).
The client must reset the set values itself.

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

Spreading context across cluster nodes

Via the QueryStartRequest SQL message protocol (for jdbc, SQL transactions)
Via the transaction protocol for handling inserts (CacheInterceptor), since inserts are not always performed on the request initiator node.