Marty, Continuous queries are certainly planned for thin clients, and that is the best way to get cache update notifications.
On Fri, May 22, 2020 at 8:32 PM Marty Jones <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]>: >>>> >>>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 [email protected] < >>>>>>> [email protected]> 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. >>>>>>>> >>>>>>>
