Skip to main content
Skip table of contents

How does cache / caching data works in Elements Connect?

Default value

Cache can be configured at Data source level and at Connected field level.

Data source cache configuration applies to all Connected fields associated with the data source, unless a specific override is set at the Connected field level.

Data source cache duration can also be used when two (or more) Connected fields are using same query (more details in FAQ "What is the behavior if two Connected fields use the same query?" ).

By default, the cache duration for a data source is set to 5 minutes (300 seconds).

Cache can either be disabled by setting the field duration to empty or 0 or it can be customized with a value greater than zero.

Changes to cache duration invalidate existing cached data; the cache will immediately be invalidated.

An example

Let's take the example of a Connected field "CF" connected to a data source.

When "CF" is edited:

  • Elements Connect evaluates the field query (and replaces dependencies by their value, if any)

  • Then, the app looks up in the field cache for an entry key matching the "Evaluated query"

    • If an entry is found in the field cache, it retrieves the response directly from the field cache

    • If there is no entry in the cache, it executes the query on the data source

      • If the request is successful, it stores the raw response in the cache associated with the "Evaluated query" key

      • Otherwise, nothing is stored in the cache

Cache FAQ

In the case of a dependency, what is the behavior if the parent field is changed?

When the parent field is changed, the Connected field that depends on it will contact the data source again to retrieve the new result set. This means its cache will be reset and refreshed with results based on the updated parent value.

What is the impact of the cache on Jira performance?

On Data Center, Cache storage can have an impact on Jira performances (can saturate Jira’s memory).

On Cloud, this is not the case: Cache has no impact on Jira or Elements Connect performances.

How can one know if the cache is being used?

You can’t guarantee that the cache will always be used. The system automatically determines whether to retrieve data from the cache or fetch fresh data based on certain conditions.

Your values will not be pulled from the cache in the following cases:

  • The field’s cache duration has expired

  • The “Evaluated query” of a field has changed

  • A new version of the Elements Connect app is deployed – Upgrading the app can invalidate the existing cache

  • The cache storage limit has been reached – When the cache reaches its configured capacity, some entries may be removed automatically to make room for new ones

Where is the cache stored?

Cache is stored in our app backend on server side.

Does it make sense to use the cache with $userInput?

Here is an explanation of how Cache behaves in the case of $userInput, which can help identifying if it make sense to configure cache in this situation.

As a reminder, $userInput can be used to retrieve what the user is typing into the field in order to apply a filter to the query and limit the results to be returned, such as:

CODE
SELECT * FROM users WHERE username like '$userInput'

In this case, each character typed into the field can trigger a different query to be cached, which could result in a large number of cached results.

For Connect custom fields (not Connected items), our software smartly manages typing latency to execute the query only after the user has stopped typing.
This ensures that only relevant results are stored in the cache. This approach prevents unnecessary queries from being cached.

Is it possible to clear the cache before it expires?

You can clear the cache manually before it expires, by changing field cache duration to 0.

Will the cache continue to work if the data source is no longer accessible?

If the data source is offline, the latest cached data will still be available for the entire cache duration you have set in the field configuration.

However, once it expires, the cache cannot be refreshed and no values will be available.

When a cache has expired, is it possible to refresh it automatically at a scheduled time (via API call for example)?

Our app currently does not provide any functionality for doing this.

Do not hesitate to reach out our Support team if you have this need.

What is the behavior if two Connected fields use the same query?

This optimization mechanism is only implemented for REST API data source and will be implemented for Database data sources in a second time.

When two Connected fields use the exact same evaluated query, Elements Connect avoids duplicate calls by using caches:

  1. Each field has its own cache duration.
    If a field’s own cache is still valid, it uses it and no call is made.

  2. If a field’s cache is empty/expired, we check the Data Source cache (shared for that query).
    If the Data Source cache entry exists and its age is ≤ the field’s cache duration (and, naturally, still within the Data Source cache duration), the field reuses those results—again no call to the underlying system. Otherwise, the field runs a fresh call, which updates both the Data Source cache and the field cache.

In practice

  • Field A (10s) and Field B (300s) share a REST DS (200s):

    • If B loads 100s after the last successful call, B can reuse the DS cache (100 ≤ 300 and 100 ≤ 200) → no new call.

    • If A loads 150s after the last call, A treats the DS cache as “too old” for its 10s policy (150 > 10) and triggers a new call, refreshing the shared entry for everyone.

What is the behavior if two Connected Fields use the same query and are used at the same time?

This optimization mechanism is only implemented for REST API data source and will be implemented for Database data sources in a second time.

Elements Connect de-duplicates simultaneous calls.
If multiple Connected fields with the same evaluated query refresh at the same time (e.g., a parent field changes or a post-function updates them together), only one outbound call to the data source is made.
The other fields wait for that call to complete and then read the shared result, so the data source is not hit multiple times.

To reduce duplicate requests, choose a Data Source cache duration that exceeds the call’s response time.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.