...

It's proposed to introduce SessionContext API that is available from the functions and provides access to the attributes in all levels order (call, application, connection).

...

1. 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 ApplicationAttributes array.
2. The parameters set in setClientInfo are passed along with each JdbcRequest (this requires a new feature in JdbcThinFeature).
3. The client must reset the set values ​​itself.

...

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

Accessing attributes

SessionContext is an entrypoint for accessing attributes on all levels and other session-level data (e.g. SecurutySubject

...

).

...

Ignite provides SessionContextProviderResource to access to SessionContext.

1. Injecting requires to have the ProviderResource doesn't require new instance of CacheInterceptor or QuerySqlFunction target class for every call (every row or key).
2. Instead single object is maintained with injected Provider .Provider implementation is responsible for extracting context SessionContext from Ignite thread.
3. Note, it proposes to make possible use non-static QuerySqlFunction to inject the resource.
   
   

/** SessionContext interface. It's an entrypoint for all attributes. */
public class SessionContext {
    /** @return Attribute by name. */
    public @Nullable String getAttribute(String attrName);

    /** @return Current SecuritySubject. */
	public @Nullable SecuritySubject getSecuritySubject();
 }
 
/** Example, use it in QuerySqlFunction. */
public static class UserDefinedFunctions {
    /** Injection performs once per query. */
    @SessionContextProviderResource
    public SessionContextProvider sesCtxProv;

     /** @return Session ID set with application attributes. */
    @QuerySqlFunction
    public @Nullable String sessionId() {             
		SessionContextreturn sesCtx = sesCtxProv.getSessionContext();

        return sesCtx == null ? null : sesCtx.getAttribute("SESSION_ID");
    }
}

...

1. No security checks are performed on the application attributes.
2. Application attributes keys and values are strings, to avoid serialization problems.
3. User should specify only few application attributes, and they should be small.
4. UserAttributes currently fill with node attributes (~50 items on node start), and they are not transferred between nodes. This process should be changed.

Discussion Links

https:// Links to discussions on the devlist, if applicable.lists.apache.org/thread/c5j5yykr6tfrnp9zprhg9j69w63r11zx

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

...