Has there been a request for event listeners for the thin clients? I am happy to roll my own implementation of the nearcache if I can get the events of when cache items within the cluster are added, modified, or deleted.
On Thu, May 21, 2020 at 2:29 PM Marty Jones <martybjo...@gmail.com> wrote: > Honestly near cache for the thin client is a must for me. Implementing > this is a huge performance gain. > > On Thu, May 21, 2020 at 5:47 AM Pavel Tupitsyn <ptupit...@apache.org> > wrote: > >> Alex, >> >> I've recently implemented .NET Native Near Cache [1]. >> It is a very similar concept, because caching is performed on platform >> side. >> >> We had requests for this from different users for quite some time. >> Users were implementing this on their own with Continuous Queries. >> Yes, it is not transactional, but it still provides a huge speedup in >> many cases. >> >> Thin Client Near Cache can be based on the same mechanism. >> Yes, it is not a trivial feature, but neither is Partition Awareness, for >> example. >> Performance is a feature. >> >> https://issues.apache.org/jira/browse/IGNITE-12691 >> >> On Thu, May 21, 2020 at 11:35 AM Alex Plehanov <plehanov.a...@gmail.com> >> wrote: >> >>> Hello, >>> >>> I don't think that near cache for thin client on Ignite level it's a >>> good idea. >>> >>> Expiration is not the only case here. For thick clients near caches are >>> transactionally consistent. For thin clients such a guarantee never can be >>> provided. >>> Near cache for thin clients will be either too heavy (and this >>> contradicts thin clients paradigm) or highly specialized (in this case it's >>> better to implement it on user level). >>> >>> Also, sometimes many thin clients are used inside one application >>> (inside one JVM for java thin client). I know deployments where thin client >>> pool approach or client per thread approach is used. In these cases, it's >>> better to have one near cache for all clients than have it inside each >>> client. >>> >>> I think it's better to provide mechanisms like event listeners or >>> continuous queries to make it possible to implement near caches on user >>> level with guarantees that best fit user's requirements. >>> >>> вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <ptupit...@apache.org>: >>> >>>> Ok, thanks for the explanation. >>>> Yes, this is a good feature, and I've had this in mind for some time. >>>> >>>> Ticket filed: https://issues.apache.org/jira/browse/IGNITE-13037 >>>> There are no immediate plans, but I think there is a possibility to >>>> achieve this by the end of the year. >>>> >>>> On Tue, May 19, 2020 at 2:52 PM Marty Jones <martybjo...@gmail.com> >>>> wrote: >>>> >>>>> The use case is having a local cache that stores most widely used >>>>> cache items in memory on server instead of having the network expense of >>>>> pulling them down every time they are requested. The main thing is the >>>>> near cache has to support removing cache items that have expired on the >>>>> server. >>>>> >>>>> The best use case I have is a web application that needs a cache item >>>>> per request. we would not want to pull the cache item from the cluster >>>>> every request. It would be way more efficient for the thin client to >>>>> have >>>>> a near cache that would hold "hot" cache items that are requested >>>>> frequently. >>>>> >>>>> On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <ptupit...@apache.org> >>>>> wrote: >>>>> >>>>>> Can you please describe the use case in more detail? >>>>>> What do you expect from such a feature? >>>>>> >>>>>> On Tue, May 19, 2020 at 2:01 AM martybjo...@gmail.com < >>>>>> martybjo...@gmail.com> wrote: >>>>>> >>>>>>> I wanted to see if there are any plans to support near caches for >>>>>>> thin clients? I think it would be a great feature. I know I could use it >>>>>>> right now. >>>>>>> ------------------------------ >>>>>>> Sent from the Apache Ignite Users mailing list archive >>>>>>> <http://apache-ignite-users.70518.x6.nabble.com/> at Nabble.com. >>>>>>> >>>>>>
