You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by "martybjones@gmail.com" <ma...@gmail.com> on 2020/05/18 23:01:31 UTC
Near Cache Support For Thin Clients
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: http://apache-ignite-users.70518.x6.nabble.com/
Re: Near Cache Support For Thin Clients
Posted by Igor Sapego <is...@apache.org>.
I personally think that this feature should be implemented in Ignite,
though maybe we should first start from Continuous Queries for thin
clients.
Best Regards,
Igor
On Mon, May 25, 2020 at 6:15 PM Pavel Tupitsyn <pt...@apache.org> wrote:
> 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 <ma...@gmail.com> 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 <ma...@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 <pt...@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 <pl...@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 <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>>>>>>>> martybjones@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.
>>>>>>>>>
>>>>>>>>
Re: Near Cache Support For Thin Clients
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <ma...@gmail.com> 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 <ma...@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 <pt...@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 <pl...@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 <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>>>>>>> martybjones@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.
>>>>>>>>
>>>>>>>
Re: Near Cache Support For Thin Clients
Posted by Marty Jones <ma...@gmail.com>.
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 <ma...@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 <pt...@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 <pl...@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 <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>>>>>> martybjones@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.
>>>>>>>
>>>>>>
Re: Near Cache Support For Thin Clients
Posted by Marty Jones <ma...@gmail.com>.
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 <pt...@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 <pl...@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 <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>>>>> martybjones@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.
>>>>>>
>>>>>
Re: Near Cache Support For Thin Clients
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <pl...@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 <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>>>> martybjones@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.
>>>>>
>>>>
Re: Near Cache Support For Thin Clients
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>>> martybjones@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.
>>>>
>>>
Re: Near Cache Support For Thin Clients
Posted by Pavel Tupitsyn <pt...@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 <ma...@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 <pt...@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 martybjones@gmail.com <
>> martybjones@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.
>>>
>>
Re: Near Cache Support For Thin Clients
Posted by Marty Jones <ma...@gmail.com>.
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 <pt...@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 martybjones@gmail.com <
> martybjones@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.
>>
>
Re: Near Cache Support For Thin Clients
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 martybjones@gmail.com <ma...@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.
>