Hazelcast get() after evict()

194 views
Skip to first unread message

Binh Nguyen

unread,
Jul 6, 2021, 8:40:09 AM7/6/21
to Hazelcast
I have a question related to get after eviction.
I have a MapStore with write-delay.
I have a function that write directly to db and then call evict() function from the map.(The eviction is done by getTransactionMap and then delete the key).

I also have another function that using nearcache to fetch the value from the same map above.

Sometimes during the write function, the get function from near cache has value null for the key.

It happen also from the normal get() function if the write-delay is not tick.

I wonder can you explain how the near cache, evict and write-delay works that it make the get result is null during that small time between the evict() triggered and write-delay.
How can i prevent that to happen?

Tom OConnell

unread,
Jul 6, 2021, 8:55:11 AM7/6/21
to Hazelcast
Hi -

I'm assuming that the near-cache is client-side, but please confirm that.
When you evict a key from a map, the near-caches receive invalidation events. I see that you wouldn't expect this to happen during the write, but it's possible as there's a write delay. The invalidation happens on the owning member first and is propagated to the other members and clients.
If the write is initiated on a client and the client sees the null key, we should look at your near-cache configuration. There are options for controlling the behavior. If you're using "INVALIDATE", the key should be removed from the near cache as soon as you begin the write and before it completes on the server If you were using "CACHE_ON_UPDATE", the key should be retained in the near-cache until the eviction message is received.
Beyond that, I'd like to understand why you evict it when you write to the database. Clearly, you may have some backend processing (i.e. triggers or streams) that changes the data. If this were the case, the evict would cause the client to see a new image of that key on the next get. Is this the case? If there is no backend processing, would leaving it in the cache to expire normally be an option?

Thanks

Tom

Binh Nguyen

unread,
Jul 6, 2021, 9:12:02 AM7/6/21
to haze...@googlegroups.com
Hi,
Yes I have function that update the value on the cache and read the value of the cache from UI using http request. 
The purpose is to write value to database and then evict the key so when the UI request for value, it will fetch the updated value from the db and also store it again to cache.
With the bad timing, when the write already triggered, user can experience the data lost because at that time, the write delay not yet expired so the key still in the cache but the value return is null. After the write delay passed, the key is evicted and the next request from UI returns the correct value.
NOTE: It might not necessarily related to the near cache. I happen also just with normal hazelcast server that serve the value using get() for the REST API to return to UI. I guess the main issue is during the write-delay, evict does not seems to evict the key and any request during that time to return the value from the cache for that key returns null.

Best Regards.
Nguyen Thanh Binh.


This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. -Hazelcast

--
You received this message because you are subscribed to a topic in the Google Groups "Hazelcast" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hazelcast/OTc1KtaylkE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/4845d94e-0303-43c1-af06-81336784d59bn%40googlegroups.com.

Tom OConnell

unread,
Jul 14, 2021, 12:35:01 PM7/14/21
to Hazelcast
Hi -

Is your app the only source of database updates? If so, then the value read after the 'evict()' would be the same as the one written from your cluster, wouldn't it? It's possible that there are triggers or many other sources of updates, but you'd have to confirm that.

Without seeing your code, I'm not sure why you're seeing a null return from your map (either the near-cache or the server-side map). Until the key is evicted, it should remain readable. As I said before, your near-cache configuration will determine the retention of the key in your local near-cache.
Is CDC an option here? Change Data Capture software can allow database servers to publish changes to a stream (take a look at https://debezium.io/). It's easy to stream these changes into kafka and then there are several paths to loading it into your cluster, including Hazelcast Jet.

CDC updates will tend to be low-latency and near real-time, but they are not transactional, so there are still potential timing issues.

Cheers

Tom
Reply all
Reply to author
Forward
0 new messages