Re: persist only on delete

2017-02-07 Thread vkulichenko
Shawn,

I don't know, sounds wrong. Do you have a unit test reproducing this?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/persist-only-on-delete-tp10438p10489.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.


Re: persist only on delete

2017-02-06 Thread shawn.du





Hi Val,just curious about why onAfterRemove(Cache.Entry(K,V) entry)entry.getValue() sometimes return null.  but I never put a null value into the cache.I have to check it to avoid NullPointerException.






ThanksShawn





On 02/7/2017 09:07,shawn.du<shawn...@neulion.com.cn> wrote: 





Hi Val,Thanks very much. CacheInterceptor is the best way.Shawn





On 02/7/2017 08:09,vkulichenko<valentin.kuliche...@gmail.com> wrote: 


Hi Shawn,

Your approach sounds a bit dangerous. Store is called within an entry lock,
which means that if you do a distributed get there, you will likely get
thread starvation. This should not happen on stable topology, but if another
node fails or joins, you can get stuck.

I think you should use interceptor instead:
https://ignite.apache.org/releases/mobile/org/apache/ignite/cache/CacheInterceptor.html

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/persist-only-on-delete-tp10438p10461.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.







Re: persist only on delete

2017-02-06 Thread shawn.du





Hi Val,Thanks very much. CacheInterceptor is the best way.Shawn





On 02/7/2017 08:09,vkulichenko<valentin.kuliche...@gmail.com> wrote: 


Hi Shawn,

Your approach sounds a bit dangerous. Store is called within an entry lock,
which means that if you do a distributed get there, you will likely get
thread starvation. This should not happen on stable topology, but if another
node fails or joins, you can get stuck.

I think you should use interceptor instead:
https://ignite.apache.org/releases/mobile/org/apache/ignite/cache/CacheInterceptor.html

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/persist-only-on-delete-tp10438p10461.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.






RE: persist only on delete

2017-02-06 Thread vkulichenko
Hi Shawn,

Your approach sounds a bit dangerous. Store is called within an entry lock,
which means that if you do a distributed get there, you will likely get
thread starvation. This should not happen on stable topology, but if another
node fails or joins, you can get stuck.

I think you should use interceptor instead:
https://ignite.apache.org/releases/mobile/org/apache/ignite/cache/CacheInterceptor.html

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/persist-only-on-delete-tp10438p10461.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.


RE: persist only on delete

2017-02-06 Thread Shawn Du
Hi, 

 

I tested that the cache value was still in memory when calling store delete 
method. For I leave write empty, so it can’t get it from persist store.

 

public void write(Cache.Entry entry)
{
//do nothing
}

 

 

Thanks

Shawn

 

发件人: Vladislav Pyatkov [mailto:vldpyat...@gmail.com] 
发送时间: 2017年2月6日 16:04
收件人: user@ignite.apache.org
主题: Re: 答复: persist only on delete

 

Hi,

 

I think it will be work, because each time when "get"  from a cache Ignite try 
to get the value from persistence story, if it will not find in memory.

 

On Mon, Feb 6, 2017 at 10:39 AM, Shawn Du <shawn...@neulion.com.cn 
<mailto:shawn...@neulion.com.cn> > wrote:

Hi,

 

In delete method, we can only get cache key.  In order to get cache entry 
value, we need get Ignite instance and get the cache.

 

Assume we already get all of them. Can we get value in the cache by the key? 
Which is still valid in cache?

 

Thanks

Shawn

 

发件人: Shawn Du [mailto:shawn...@neulion.com.cn <mailto:shawn...@neulion.com.cn> 
] 
发送时间: 2017年2月6日 15:12
收件人: user@ignite.apache.org <mailto:user@ignite.apache.org> 
主题: persist only on delete 

 

Hi,

 

I have a case which cache entry will be update frequently, and I only want to 
persist it when the cache is manually remove(cache will not change anymore) by 
me.

 

For this case, It is a good idea to implement persist logic in delete/deleteAll 
method while write/writeAll do nothing?

 

@Override
public void delete(Object o)
{
//do nothing, we never have this operation.
}

 

 

Thanks

Shawn





 

-- 

Vladislav Pyatkov



RE: persist only on delete

2017-02-06 Thread Shawn Du
Hi,

 

Have a quick test, it works as I expect. I only test with sync API.

Still want to get comments about it. 

 

Thanks

Shawn

 

发件人: Shawn Du [mailto:shawn...@neulion.com.cn] 
发送时间: 2017年2月6日 15:39
收件人: user@ignite.apache.org
主题: 答复: persist only on delete 

 

Hi,

 

In delete method, we can only get cache key.  In order to get cache entry
value, we need get Ignite instance and get the cache.

 

Assume we already get all of them. Can we get value in the cache by the key?
Which is still valid in cache?

 

Thanks

Shawn

 

发件人: Shawn Du [mailto:shawn...@neulion.com.cn] 
发送时间: 2017年2月6日 15:12
收件人: user@ignite.apache.org <mailto:user@ignite.apache.org> 
主题: persist only on delete 

 

Hi,

 

I have a case which cache entry will be update frequently, and I only want
to persist it when the cache is manually remove(cache will not change
anymore) by me.

 

For this case, It is a good idea to implement persist logic in
delete/deleteAll method while write/writeAll do nothing?

 

@Override
public void delete(Object o)
{
//do nothing, we never have this operation.
}

 

 

Thanks

Shawn



Re: 答复: persist only on delete

2017-02-06 Thread Vladislav Pyatkov
Hi,

I think it will be work, because each time when "get"  from a cache Ignite
try to get the value from persistence story, if it will not find in memory.

On Mon, Feb 6, 2017 at 10:39 AM, Shawn Du <shawn...@neulion.com.cn> wrote:

> Hi,
>
>
>
> In delete method, we can only get cache key.  In order to get cache entry
> value, we need get Ignite instance and get the cache.
>
>
>
> Assume we already get all of them. Can we get value in the cache by the
> key? Which is still valid in cache?
>
>
>
> Thanks
>
> Shawn
>
>
>
> *发件人:* Shawn Du [mailto:shawn...@neulion.com.cn]
> *发送时间:* 2017年2月6日 15:12
> *收件人:* user@ignite.apache.org
> *主题:* persist only on delete
>
>
>
> Hi,
>
>
>
> I have a case which cache entry will be update frequently, and I only want
> to persist it when the cache is manually remove(cache will not change
> anymore) by me.
>
>
>
> For this case, It is a good idea to implement persist logic in
> delete/deleteAll method while write/writeAll do nothing?
>
>
>
> @Override
> public void delete(Object o)
> {
> //do nothing, we never have this operation.
> }
>
>
>
>
>
> Thanks
>
> Shawn
>



-- 
Vladislav Pyatkov


答复: persist only on delete

2017-02-05 Thread Shawn Du
Hi,

 

In delete method, we can only get cache key.  In order to get cache entry
value, we need get Ignite instance and get the cache.

 

Assume we already get all of them. Can we get value in the cache by the key?
Which is still valid in cache?

 

Thanks

Shawn

 

发件人: Shawn Du [mailto:shawn...@neulion.com.cn] 
发送时间: 2017年2月6日 15:12
收件人: user@ignite.apache.org
主题: persist only on delete 

 

Hi,

 

I have a case which cache entry will be update frequently, and I only want
to persist it when the cache is manually remove(cache will not change
anymore) by me.

 

For this case, It is a good idea to implement persist logic in
delete/deleteAll method while write/writeAll do nothing?

 

@Override
public void delete(Object o)
{
//do nothing, we never have this operation.
}

 

 

Thanks

Shawn



persist only on delete

2017-02-05 Thread Shawn Du
Hi,

 

I have a case which cache entry will be update frequently, and I only want
to persist it when the cache is manually remove(cache will not change
anymore) by me.

 

For this case, It is a good idea to implement persist logic in
delete/deleteAll method while write/writeAll do nothing?

 

@Override
public void delete(Object o)
{
//do nothing, we never have this operation.
}

 

 

Thanks

Shawn