Motivation

When processing data, the user wants to have access to client attributes - an associative array specified on the client application side. Usage scenarios:

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 session and saves it along with the data).
3. To optimize the transfer of parameters to processing functions (for example, many successive QuerySqlFunction use the same parameter and it is convenient to take it from the context, rather than transfer it separately to each function).

The requirements also include:

1. Attributes must also be accessible from user functions (QuerySqlFunction, CacheInterceptor).
2. Setting attributes via protocols: thick client, thin client, jdbc:thin.
3. Attribute values ​​can change during the life of the connection (a connection from a connection pool can be successively used by different applications).

Ignite does not have a similar public API:

ServiceCallContext helps solve similar problems, but has several limitations. The main one is that it is only available in calls via the IgniteService API and cannot be used for SQL queries from the jdbc side.
UserAttributes - allows you to set user attributes, but the attribute values ​​are fixed for the entire lifetime of the connection.
A similar context mechanism exists in Oracle [1] and is used by some of our customers. Implementing such an API would help users migrate applications from Oracle to Ignite.

Description

// Provide the design of the solution.

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

Discussion Links

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

Reference Links

// Links to various reference documents, if applicable.

Tickets

// Links or report with relevant JIRA tickets.