Re: Programmatically triggering of write behind
Hello! You may call org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore#forceFlush when deciding to evict some entries, assuming you are doing it manually. Regards, -- Ilya Kasnacheev ср, 9 июн. 2021 г. в 11:21, r_s : > Hello All, > I am running a partitioned cache with native persistence and write-behind > to > a DB. Because the DB is fairly slow, I decided to use write-behind not > write-through. Out of many, mainly performance reasons it makes sense to > also use native persistence instead of only in memory caching. > In order to regularly clean up the cache I decided to implement time based > and state based eviction on the cache. For time based eviction I used > cache.setExpiryPolicyFactory(). > State based eviction is implemented by a service that deletes an entry from > the cache as soon as a certain field has reached a final state. > I experience the following problem: Sometimes the state changes faster than > write behind, hence the final state of my cache entry will not be written > behind to the DB. > Thus my questions: > - Is there any way to programmatically trigger a write behind on a cache? > - Is there maybe any Ignite internal option of marking a cache entry as > expired as soon as a certain state is reached? > - Will the ExpiryPolicy take into account the configured write-behind? > Meaning, will it trigger a write behind before deleting the entry if it has > not been written into the DB before? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Programmatically triggering of write behind
Hi Alexey, thank you for your answer, this confirms what I expected. For clarification: I do not want my DB to evict any entries, I just want to make sure alle updates on the cache entries are written before the entries are removed from the cache. I have not designed the architecture of native + external persistence, I am not sure whether it really has any performance advantages over pure in memory caching (the argument here was to be able to read more quickly from disc than from db if an entry is not held in memory anymore). But I guess I will have to go for some custom consistency check. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Programmatically triggering of write behind
Cache expiry policy evicts entries only from the cache and native persistent store: the external DB is not modified. So your expiry policy has nothing to do with write-behind. If you want to evict entries from both the cache and external DB you may consider implementing such a policy as a replicated Ignite service. It would not be using Ignite expiry policy so your original question about write-behind would not be applicable to such a design. Also, do you really need both native and external persistence? Ignite does not guarantee consistency in this case and you would need to develop a custom mechanism to make sure the data in Ignite and external DB is consistent after a failure. ср, 9 июн. 2021 г. в 11:21, r_s : > Hello All, > I am running a partitioned cache with native persistence and write-behind > to > a DB. Because the DB is fairly slow, I decided to use write-behind not > write-through. Out of many, mainly performance reasons it makes sense to > also use native persistence instead of only in memory caching. > In order to regularly clean up the cache I decided to implement time based > and state based eviction on the cache. For time based eviction I used > cache.setExpiryPolicyFactory(). > State based eviction is implemented by a service that deletes an entry from > the cache as soon as a certain field has reached a final state. > I experience the following problem: Sometimes the state changes faster than > write behind, hence the final state of my cache entry will not be written > behind to the DB. > Thus my questions: > - Is there any way to programmatically trigger a write behind on a cache? > - Is there maybe any Ignite internal option of marking a cache entry as > expired as soon as a certain state is reached? > - Will the ExpiryPolicy take into account the configured write-behind? > Meaning, will it trigger a write behind before deleting the entry if it has > not been written into the DB before? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > -- Best regards, Alexey
