Hi Dmitriy! Could you please clarify in more detail what such a cache should look like? Near caches participate in transactions, whether this should be supported? Also, should the cache entries participate in cache/SQL queries?
In case you talk about a lightweight cache that just stores results of cache puts/gets and is aware of remote changes, then common libraries such as Guava or Caffeine can be used. See simple example how this can be done [1] on the client side with Caffeine and ContinuousQuery. [1] https://gist.github.com/timoninmaxim/7ba84e89db58574a4da03023236be555 On Mon, Dec 30, 2024 at 10:47 AM Pavel Tupitsyn <ptupit...@apache.org> wrote: > I think it is a great idea. > We can use Continuous Query to keep the local entries up to date. I've seen > this approach in some real-world Ignite-based applications. > > Note that we have .NET Platform Cache [1] which is quite similar, but works > on thick clients and embedded servers only. > > [1] https://ignite.apache.org/docs/latest/net-specific/net-platform-cache > > On Fri, Dec 27, 2024 at 9:09 PM Dmitriy Pavlov <dpav...@apache.org> wrote: > > > Hi Folks, > > > > What do you think about the idea of supporting a lightweight cache over > > records in the thin client? > > > > In the thick client we have near caches (yes, of course, they add > > complexity to the product). There is no such option in the thin one. > > > > Yes, you can cache this with third-party tools like guava. At the same > > time, my idea is that the product could somehow notify such mini-cache > > about changes (probably in batches). > > > > For some scenarios, asking server nodes for the rarely changed cache > value > > is overhead. And I remember Ignite 1.x caches were on-heap (without > > off-heap - on-heap data copying cost) > > > > Sincerely, > > Dmitriy Pavlov > > >
