...

When processing data, users want to have access to non-tabular (not stored in cache structures) data. Example of such data is application attributes - an associative array specified on an application side. Usage scenarios:

To run certain business logic that depends on the value of the attribute (for example, the application language [2], progress monitoring [4]).
To audit changes in the database (for example, CacheInterceptor extracts the user from the attributes and saves it along with data).
To optimize the transfer of parameters to processing functions (for example, multiple QuerySqlFunction use the same parameter and it is convenient to take it from the attributes, rather than transfer it separately to each function).

Another examples of non-tabular data that can be accessed is are SecuritySubject, UserAttributes and current Transaction.

...

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

...

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 single SQL queriesoperations or transactions.
UserAttributes - allows to set user attributes, but the attribute values are fixed for the entire lifetime of the connection.

...

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