# Cache & Share vs Cache Query Results

**URL:** <https://forum.inductiveautomation.com/t/cache-share-vs-cache-query-results/99922>\
**Category:** Ignition\
**Tags:** perspective, database, ignition81\
**Created:** [December 17, 2024, 12:22pm UTC](https://forum.inductiveautomation.com/t/cache-share-vs-cache-query-results/99922 "2024-12-17T12:22:56Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [December 17, 2024, 4:19pm UTC](https://forum.inductiveautomation.com/t/cache-share-vs-cache-query-results/99922/2 "2024-12-17T16:19:05Z")

</div>

Named query caching is a distinct layer from the 'Cache & Share' option available in some Perspective binding types.

Named query caching works by keying off the named query path plus parameters, with a fixed expiration time.

So, let's have sessions A and B.  
Both have a query binding, not cache & share, set to run a named query with a cache time of 5 seconds.

If A issues a query, and it returns a value, then within the next five seconds any **identical** query (including all parameter values) issued by B will hit the cache and not require any database interaction.

If A issues a query, and _before it returns_, B issues the same query - the underlying query will be executed twice. The second query will not 'wait' for the cache to be built.

If A issues a query, and it returns a value, then B issues a query _after_ five seconds, B issues a new query and builds a new cache entry that will then expire after five seconds.

* * *

Now, the 'cache and share' value cache mechanism works on fundamentally the same principle, but at a different layer, because it's an agnostic mechanism that's used internally in various Perspective components as well as exposed via bindings.

The basic principle is the same, but the implementation works somewhat differently:  
If A runs a binding and it returns a value, then within the _poll rate of the binding_, B runs the same binding, B will get the cached value.

If A runs a binding, and, before it has returned, B runs the same binding, B will 'wait' on the **same** task to return a result - no duplicate work.

If A runs a binding and after it's expired, B runs the same binding, B will run a new task and cache a new result.

* * *

Finally, the _interaction_ between 'cache and share' and 'named query caching' - named query execution is a _task_ that the cache and share system can execute. So even if the cache & share evaluation attempts to run a task twice, it could still hit the named query cache and return a cached result immediately.

---

_[View the full topic](https://forum.inductiveautomation.com/t/cache-share-vs-cache-query-results/99922)._