Evaluate Global Resources Cache Within Provider Instances

[Torres-ssf]

The current implementation of the resources cache, managed by the Provider instance, utilizes a global cache.

This design ensures that the cache is shared among all Provider instances within the same dApp. This approach was chosen due to the possibility that multiple providers may be instantiated from different parts of the dApp, and transactions can be submitted from these various instances using resources owned by the same address.

While the global cache design has its advantages, it also introduces some unintentional issues:

1. Each Provider instance can set its cache Time-To-Live (TTL), leading to confusion since the actual cache is shared among all instances.
2. Developers might expect each Provider instance to manage its own cache independently, leading to potential misunderstandings.

Given the potential unintentional problems, this issue should serve as a reminder to continuously evaluate if another approach is more suitable.

[arboleya]

Should we make the setter for the TTL a static method on the provider class?

[nedsalk]

@arboleya yes, if we're going to make the cache static then we should make the TTL setter static as well.

public class Provider {
  static cache?: ResourceCache = new ResourceCache(20000);
  
  static updateCacheTtl(ttl: number) {
    if (ttl === -1) { this.cache = undefined; return; }
    const activeData = this.cache?.getActiveData();
    // activeData as the second argument is used to invalidate the data based on the new ttl
    this.cache = new ResourceCache(ttl, activeData);
  }
}

I'm not sure about the name of updateCacheTtl but that's the idea.

[nedsalk]

@Torres-ssf Regarding the cache being public, I know that you had some reasoning behind it but I can't remember it... What was it?

[maschad]

Closing this as not planned based on investigations

See more here