ID	IEP-143
Author	Mikhail Petrov
Sponsor
Created	04 Feb 2026
Status

Motivation

Currently, many Ignite components use the following approach: internal data (context) is attached to an operation and is accessed during its execution.
This approach is often implemented using ThreadLocal variables.

Examples of components that use the approach described above, along with their corresponding context classes:

• Cache — CacheOperationContext
• Security — SecurityContext
• Tracing —  Span
• Compute — TaskExecutionOptions

and so on.

While the ThreadLocal approach eliminates the need for developers to manually propagate the context, it can also lead to errors when an operation is executed in a multithreaded environment.
Consider a situation in which an operation begins on one thread and continues on another. This can occur, for example, if a subtask is explicitly submitted to a thread pool or if IgniteFuture#listen is used to suspend the operation and resume it on the thread that completes the IgniteFuture.
In all such cases, the developer must manually restore the context in the thread that continues executing the operation; otherwise, the operation context stored in the ThreadLocal variable will be lost.

In some cases, losing the context associated with an operation can be critical. For example, losing the SecurityContext, which stores information about the initiator, can lead to incorrect authorization decisions and inaccurate auditing.

Examples of context propagation problems:

• IGNITE-23958
  
• IGNITE-16405
• IGNITE-15101

This IEP is intended to provide a robust mechanism for propagating arbitrary operation context that preserves the convenience of the ThreadLocal approach while minimizing the risk of operation context loss in a multithreaded environment.   

Description

The following steps are proposed to resolve the described problem:

1.  Create an ThreadLocal storage (Context) with the following properties
           a) Ignite-independent
           b) stores arbitrary attributes and their corresponding values
           c) provides the ability to update attribute values
           d) provides the ability to automatically undo the last Context update, restoring previous attribute values, after the corresponding operation completes
           e) provides the ability to creates a snapshot of stored attributes and their values
           f) provides the ability to restores attribute values from snapshot to Context in another thread
   
   This will help create a unified mechanism for attaching arbitrary data to an operation for its duration, as well as the ability to move context attribute values ​​between threads.
   
   
2. Integrate the ability to capture Context Attributes values via snapshot creation to Ignite Thread Pools and Ignite Futures.
   Methods like IgniteThreadPooExecutor#submit and IgniteFuture#listen must automatically capture and save Context state along with the closure that may potentially be executed in another thread and restore saved Context before executing it.

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.