ThreadContext in SAP Cloud SDK Version 4

With the release of version 4.0.0, the ThreadContext has seen major changes in the SAP Cloud SDK.
This blog post will explain the changes we made that simplify running tasks on different threads with the ThreadContext attached.

What is a ThreadContext?

The SAP Cloud SDK for Java provides a so-called ThreadContext.
It serves as thread-safe storage for potentially sensitive information.
A few of the most important objects stored are:

• The current Tenant
• The current Principal (User)
• The JSON Web Token (JWT)

This information is used throughout the SAP Cloud SDK to provide features like tenant and principal isolation, JWT verification and authorization against other systems and services.
Every servlet that is received in its own thread, will receive a ThreadContext.
This ensures different tenants and users are properly isolated.

A Typical Use Case

Let’s say we need to run a lengthy operation upon receiving a request.
The simple solution would be to block the servlet for as long as the operation takes:

@RestController
public class HelloWorldController
{
    @GetMapping( "/hello" )
    public String getHello()
    {
        final ThreadContext currentContext = ThreadContextAccessor.getCurrentContext();
        database.store(currentTenant);// long-running operation
        return "Hello";
    }
}

Because the Spring servlet has its own thread we automatically get access to the ThreadContext.

But our users now experience long loading times because the servlet takes a long time to answer.
We need to offload the long-running operation to another thread.

Asynchronous Operations with SAP Cloud SDK Version 3

We can call an @Async annotated method:

@RestController
public class HelloWorldController
{
    @Autowired
    private DatabaseAccess databaseAccess;

    @GetMapping( "/hello" )
    public String getHello()
    {
        databaseAccess.store();
        return "Hello";
    }
}

The @Async method must be public in another class to be executed in a separate thread:

@EnableAsync
@Configuration
public class DatabaseAccess
{
    @Async
    public String store()
    {
        final ThreadContext currentContext = ThreadContextAccessor.getCurrentContext();// doesn't work
        database.store(currentTenant);// long-running operation
        return "success";
    }
}

However, this breaks the Multi Tenancy of the SAP Cloud SDK.
We cannot access the current tenant in the new thread.

Propagate the ThreadContext

We can try to use the ThreadContextExecutor to propagate the ThreadContext to the new thread:

@RestController
public class HelloWorldController
{
    @Autowired
    private DatabaseAccess databaseAccess;

    @GetMapping( "/hello" )
    public String getHello()
    {
        final ThreadContextExecutor executor = new ThreadContextExecutor();
        databaseAccess.store(executor);
        return "Hello";
    }
}

@EnableAsync
@Configuration
public class DatabaseAccess
{
    @Async
    public String store( ThreadContextExecutor executor )
    {
        return executor.execute(() -> {
            final ThreadContext currentContext = ThreadContextAccessor.getCurrentContext();// unreliable
            database.store(currentTenant);// long-running operation
            return "success";
        });
    }
}

But the access is unreliable because the ThreadContext will get removed when the servlet is finished.
We can also see that the resulting code has a lot of boilerplate code.
Let’s take a look at how this use case would be done with SAP Cloud SDK 4.

Asynchronous Operations with SAP Cloud SDK Version 4

With version 4 you can simplify your code for running asynchronous tasks with the newly introduced ThreadContextExecutors:

Future runningTask = ThreadContextExecutors.submit(() -> operation());

This functionality is conveniently integrated to work with Springs @Async annotation like so:

@RestController
public class HelloWorldController
{
    @Autowired
    private DatabaseAccess databaseAccess;

    @GetMapping( "/hello" )
    public String getHello()
    {
        databaseAccess.store();
        return "Hello";
    }
}

@Configuration
public class DatabaseAccess
{
    @Async
    public void store()
    {
        database.store(TenantAccessor.getCurrentTenant());// long-running operation
    }
}

This is thanks to this @Configuration all methods annotated with @Async will have the ThreadContext available:

@EnableAsync
@Configuration
public class AsynchronousConfiguration implements AsyncConfigurer
{
    @Override
    public Executor getAsyncExecutor()
    {
        return ThreadContextExecutors.getExecutor();
    }
}

This already comes out of the box on newly generated applications such as scp-cf-spring.
You can read more about the @Async functionality here.

Configuring the Executor

The ThreadContextExecutors class leverages a single ThreadContextExecutorService instance that can be configured.

You can create a custom ThreadContextExecutorService, for example to use a different thread pool, via:

ThreadContextExecutorService executor = DefaultThreadContextExecutorService
            .of(Executors.newFixedThreadPool(3));

// use it directly:
executor.submit(myTask);

// or set it to be used by the static ThreadContextExecutors API:
ThreadContextExecutors.setExecutor(executor);
ThreadContextExecutors.submit(myTask);

CAP Integration

When using CAP the tenant, principal, and headers are derived from the RequestContext.
Use the cds-integration-cloud-sdk dependency to propagate the context out of the box when using our APIs.
Please refer to the documentation on how to override existing values in the CAP context.

Summary

The new ThreadContextExecutors allows you to run tasks on different threads with the ThreadContext attached.
It can be integrated with Spring and CAP, and can also be configured.
For more details, please refer to the documentation or the upgrade guide.

Share Your Feedback

Do you have any questions on the new features?
Or are you struggling with the upgrade?
Don’t hesitate to share your feedback in the comments below, ask a question in the Q&A or to create a dedicated issue on our GitHub.