Per Web Request Caching services

jakobjo · January 2, 2018, 11:41pm

Has anyone been using per web request caching for your spring wired services?
Used by jersey rest services…

If so, how did you implement it?
Anything you can recommend or recommend against?

daniel · January 3, 2018, 7:54pm

Can you expand on what you mean with “per web request caching”?

jakobjo · January 5, 2018, 10:39pm

Sometimes rest endpoints are implemented by a hierarchy of services which could all be getting the same value from a database or a slow resource.

One simple example is a POST method taking in a issueId and passing it to a web of services. All services requiring to use something from the issue would be required to query the issue. A simple approach would be to cache the getIssue method PerWebRequest so that through one web request the database would only be hit once per issue.

Of course one could design the software so this is not needed.

It would be very nice if atlassian had a cache that could be created with this lifestyle instead of doing some IoC magic myself.

I’m interested to see how others have solved this with caching and how.

Here is an article on java spring scopes that could help.

I have much more experience in IoC from Net, there CastleWindsor and more IoC providers support this feature.

PerWebRequest
Instance of a component will be shared in scope of a single web request. The instance will be created the first time it’s requested in scope of the web request. Releasing it explicitly does nothing. Instance will be released upon the end of the web request.

From source:

github.com

castleproject/Windsor/blob/master/docs/lifestyles.md

# Lifestyles

When you have two classes: `HomeViewModel` and `ApplicationSettingsViewModel`, both with dependency on `IUserService`, should they both have the same instance of the user service, or each get their own?
When you go to application settings window, close it, and then open again, should you get the same instance of `ApplicationSettingsViewModel` or a new one?
When a component's instance is no longer needed, who and how should clean up after it: dispose it if needed, unsubscribe from receiving event aggregator's events and so on?

The answer is - it depends. The behavior is controlled by what's called the lifestyle of your components. Lifestyle controls in what scope instances are reused, and when to release them (that is do all the necessary clean up steps and then let it go for the Garbage Collector to destroy).

## Standard lifestyles: the common ones

Out of the box Windsor provides set of lifestyles that cover most real life scenarios.

### Singleton

Singleton components will only produce a single instance that is bound to the container. The instance will be created the first time someone requests it, and subsequently reused every time it's needed. Explicitly releasing singletons  (by calling `container.Release(mySingleton)`) does nothing. The sole instance will be released when the container it's registered with is disposed.
This is how you register a component as singleton:

```csharp
Container.Register(Component.For<MySingletonComponent>().LifestyleSingleton());
```

This file has been truncated. show original

jakobjo · January 7, 2018, 10:20pm

I can see Issues are cached f.x. here:
RequestCachingIssueManager

So to accomplish per web request caching I can use:
JiraAuthenticationContextImpl.getRequestCache

Don’t know why I didn’t think of looking at the source code before

daniel · January 8, 2018, 6:21pm

The Atlassian products aren’t really set up to handle caching in that manner. The reason I’m saying that is because of the plugin framework (and datacenter). Since all of the plugins are sandboxed away in the osgi space (the underlaying framework that p2 uses) they don’t really know about other apps installed in the instance. The host products are a combination of of core functionality (webapp) and host apps (in case of Jira - the project administration is an app for example). If you applied caching based on url paths - you’d find the cache available in some cases and not in same cases. The other issue is that there is no guarantee that the urls will mean what you think they’ll mean. Any one could create a servlet at /plugins/servlet/configuration for example…

There is a Cache Service at Atlassian Cache 2 overview (that doc is for Confluence but it’s a generic service) that you can (and probably should) use for your caching needs. Your best bet is to use that and name space your cache with your plugin (in fact - name space everything when you interact with something outside of your app).

jakobjo · September 10, 2018, 12:28pm

I think there is some misunderstanding.

I’m not concerned with other Nodes, as one web request is only run on one node.

So for method in my plugin MyService.SomeMethod(x) I want to cache it for the duration of a single web request. This is because this method is called multiple times within one web request and is time consuming. This method is not shared between plugins.

The Cache Service you mentioned cannot do this.

It seems JiraAuthenticationContextImpl.getRequestCache but it is deprecated but there is also a RequestCacheFactory which is not deprecated and seems to do the trick.

I cannot find any documentation for this

remie · September 10, 2018, 12:36pm

@jakobjo haven’t read the full thread, but if you are looking for undocumented features, you should refer to the source code. You can download sources from my.atlassian.com if you’ve purchased a copy of Jira (can be the $10 license).

Please keep in mind that in most cases this is private API and as such usage is not supported by Atlassian. In general, that means that the behaviour can change, be deprecated or even removed without notice.