...

Motivation

Currently user have some opportunities Ignite provides a few options to set custom attributes on client side :

1. Call level - ServiceCallContext
2. Application level - no
3. Connection level - UserAttributes, SecuritySubject

It has limitations: 

1. ServiceCallContext helps solve similar problems, but has several limitations - available only by calls via the IgniteService API and cannot be used for primitive cache operations.
2. UserAttributes - allows to set user attributes, but the attribute values ​​are fixed for the entire lifetime of the connection.

While processing data users want to have access to application specific non-tabular (not stored in cache structures) data: 

- per call (ServiceCallContext) or per connection (UserAttributes). But there is no opportunity to specify attributes on "application level". Scenario is:

1. Ignite connections from connection pool are used by different applications.
2. While processing data application need access to application Application attributes - an associative array of Strings specified on an application side. Business logic might depend on such attributes - application language, application name for audit, etc ([2], [4]).

It's proposed to provide such opportunity. Then there will be hierarchy of attributes:

1. Call level - ServiceCallContext
2. Application level - ApplicationAttributes
3. Connection level - UserAttributes, SecuritySubject

User defined functions might want access to different level of attributes. For example, 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 fine-grained access control.

...

Then it's proposed to introduce API that provides access to all this attributes while processing data in hierarchical order.

Requirements:

1. The attributes

...

The requirements:

1. The data ​​are explicitly set by user on application sideapplication on Ignite API entry point (Ignite, IgniteClient, JDBC).
2. The data attributes are fixed for every Ignite API call (can't be changed in the middle of the data processing).
3. The data might be changed during the life of the connection (a connection from a connection pool can be sequentially used by different applications).The data attributes must be accessible in stored functions on all nodes participated in requests and queries:
   1. QuerySqlFunction
   2. CacheInterceptor
   3. Service
   4. ComputeTask, ComputeJob

...

1. ServiceCallContext helps solve similar problems, but has several limitations - available only by calls via the IgniteService API and cannot be used for primitive cache operations.
2. UserAttributes - allows to set user attributes, but the attribute values ​​are fixed for the entire lifetime of the connection.
3. ClientListenerConnectionContext - it's available only on single node which directly accepts a client connection.
4. ComputeTaskSession - this mechanism is available only within Compute API. It allows attributes to be changed during task lifetime, use-case is different - send sync/async notifications between jobs about events happened during task lifetime.

Attributes hierarchy:

...

Similar mechanisms in other DBMSs:

1. Application, Client contexts mechanisms exist in Oracle [1] and they are widely used [6].
2. Custom session variables exist in DBMS like SQLServer [8], Snowflake [7], MySQL [9].

Naming:

...

Description

...

Accessing application attributes

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

...

...

language	java

...

/** 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 application attributes

Ignite 

1. Users set attributes with IgniteCache#withApplicationAttributes.
2. Application attributes are propagated with all messages sent within operation on remote nodes (similar to GridIoSecurityAwareMessage)
3. Application attributes set to ThreadLocal<Map<String, String>>  in each thread that process operation (similar to SecurityContext#withSecurityContext() ).

...

// Example of usage.
try (Ignite ign = Ignition.start(ignCfg)) {
    Map<String, String> appAttrs = F.asMap("SESSION_ID", "1234");

	IgniteCache<?, ?> cache = ign.cache("CACHE").withApplicationAttributes(appAttrs);	

 	...
}

IgniteClient (Java) 

1. Users set attributes with ClientCache#withApplicationAttributes.
2. 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");

	ClientCache<?, ?> cache = cln.cache("CACHE").withApplicationAttributes(appAttrs);	

 	...
}

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");
 
    ...
}

Accessing application attributes

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

/** 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");
    }
}

Risks and Assumptions

1. No security checks are performed on the application attributes.
2. Application attributes keys and values are strings, to avoid serialization problems.
3. Application attributes should be small. 

Discussion Links

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

Reference Links

[1] https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/using-application-contexts-to-retrieve-user-information.html#GUID-51C9D5FA-6787-4F05-82EF-A5968BEDC5A0

...

[9] https://dev.mysql.com/doc/refman/8.4/en/user-variables.html

Tickets

// Links or report with relevant JIRA tickets.