Skip to content

[Java V4] Remove RequestScopedHttpClientCache #865

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Johannes-Schneider merged 1 commit into from
Jun 23, 2022
Merged

[Java V4] Remove RequestScopedHttpClientCache #865

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 0 additions & 24 deletions docs/java/features/connectivity/destinations.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -100,30 +100,6 @@ DestinationAccessor.getLoader().tryGetDestination(destinationName, options);

See the section on [destination options](#building-destination-options) below.

### Using the SAMLAssertion Authentication Type

Using the [`SAMLAssertion`](https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/d81e1683bd434823abf3ceefc4ff157f.html) authentication types requires a different caching strategy for `HttpClient`s.
This is because upon authentication at the target system, a session cookie is returned, which is stored within the used `HttpClient` instance.
For subsequent calls, the service then expects authenticated clients to include their session cookie.

By default, the SAP Cloud SDK uses the `RequestScopedHttpClientCache` to store `HttpClient` instances for the duration of a specific (incoming) request.
Using this default strategy results into deleting the `HttpClient` (together with the session cookie) that was used to authorize at the target system, once the initial request has been handled.
To avoid authorizing over and over again, the SAP Cloud SDK offers the `TimeScopedHttpClientCache`, which keeps existing `HttpClient`s for a certain period of time.
These instances are then automatically reused for consecutive (incoming) requests, so that the session is retained.

Switching the cache can be done as follows:

```java
// run this code once in a setup step, afterwards HttpClient instances are kept for 5 minutes
HttpClientAccessor.setHttpClientCache(new TimeScopedHttpClientCache(5, TimeUnit.MINUTES));
```

:::note Hint

The cached `HttpClient` instances are also isolated based on the tenant and principal.

:::

## Supported Proxy Types

| Proxy Type | Parameter Name |
Expand Down
3 changes: 1 addition & 2 deletions docs/java/features/multi-tenancy/thread-context.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,9 +51,8 @@ Additionally, if the `Authorization` header contains a `JWT` from the [`AppRoute
- Pull the _Tenant_ and _Principal_ information from it

:::tip Integration with CAP
In case you are using CAP (with the `cds-integration-cloud-sdk` dependency) the Tenant,Principal information and Headers will **instead** be derived from the [CAP Request Context](https://cap.cloud.sap/docs/java/request-contexts).
In case you are using CAP (with the `cds-integration-cloud-sdk` dependency) the Tenant, Principal, and Headers will **instead** be derived from the [CAP Request Context](https://cap.cloud.sap/docs/java/request-contexts).
That also means that the `ThreadContext` will not be used when accessing this information.
Please note that the `RequestScopedHttpClientCache` which is the default being used by the SAP Cloud SDK cannot work with this approach.
:::

## Running Asynchronous Operations
Expand Down