Page History

...

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

Ignite does not have a such API:

Attributes API that aren't part of the IEP:

1. ClientListenerConnectionContext#attributes - it's how client stores UserAttribute in connection context.
2. ComputeTaskSession#setAttribute 
3. 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.
4. UserAttributes - allows to set user attributes, but the attribute values ​​are fixed for the entire lifetime of the connection.
5. ClientListenerConnectionContext - it's available only on single node which directly accepts a client connection.
6. 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.

...

1. Users set attributes with IgniteCache#withApplicationAttributes Ignite#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() ).

...