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.

...

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:

...

   /** */
   private static final ContextAttribute<String> ATTR = ContextAttribute.newInstance("initial-value");
 
   /** */
   public static void main(String[] args) {
       ContextSnapshot snapshot;
 
       try (Scope scope = Context.set(ATTR, "test")) {
           String attrVal = Context.get(ATTR);
       }
 
       ContextSnapshot snapshot = Context.createSnapshot();
 
       try (Scope scope = Context.restoreSnapshot(snapshot)) {
           String attrVal = Context.get(ATTR);
       }
   }

Risks and Assumptions

The proposed improvement allows to largely eliminate the problem of losing the context of an operation in a multi-threaded environment, but, unfortunately, does not solve this problem completely.
External libraries may provide the ability to submit code for multithreaded execution, but obviously do not support context propagation. Like JDK mechanism - java.util.stream.BaseStream#parallel. Misuse of such mechanisms can still result in loss of operation context and should be treated with caution.

Ubiquitous support for context capture and recovery may impact performance and GC. Although preliminary tests did not reveal any noticeable impact.

Discussion Links

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

Reference Links

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ScopedValue.html

...

https://logback.qos.ch/manual/mdc.html

Tickets