...

Motivation

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

...

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

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).

...

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

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.