Hello, I post an answer I received from Andrei, which completes and extends his first answer on the subject.
Regards, Ari From: Andrei Aleksandrov <[email protected]> Sent: Wednesday, September 11, 2019 4:02 PM To: Ari Erev <[email protected]> Subject: Re: Concurrent threads updating the same cache item Hi, Ignite will execute the logic of compute task in separate Runnable instance that will be executed in a single thread of https://apacheignite.readme.io/docs/thread-pools#section-public-pool.<https://apacheignite.readme.io/docs/thread-pools#section-public-pool> So one compute will be executed in one thread on the same node. But in case if you start several distributed computes tasks and they will work with the same caches then yes it's possible that there will be the race between them and you will require to synchronize the operations. It fully depends on your logic - should you lock on a “read then update” scenario or not. BR, Andrei From: Andrei Aleksandrov <[email protected]><mailto:[email protected]> Sent: Thursday, September 5, 2019 6:47 PM To: [email protected]<mailto:[email protected]> Subject: Re: Concurrent threads updating the same cache item Hi, When you start the compute task then it (and code from there) will be executed on every server (that were chosen) consistently in the single thread. But if you will try to broadcast the same task on several servers then race between different tasks on different servers is possible in this case. To avoid it you can try to use the transactions API (to provide atomicity of get-update-put operation) or distributed locks for updated keys: https://apacheignite.readme.io/docs/transactions https://apacheignite.readme.io/docs/distributed-locks<https://apacheignite.readme.io/docs/distributed-locks> BR, Andrei 9/5/2019 5:41 PM, Ari Erev пишет: Hello, This question is related to the question by “humenius”, with subject: “Race condition and conflicts during cache modifications?” – but I believe it is a simpler case… When code is run on an Ignite server node (such as from a distributed compute, or service) – is all access to a specific object (object with a specific key) – done from one (the same) specific thread? The reason I am asking is this: Some examples of Ignite code on GitHub and the ones that are embedded in White Paper articles from GridGain contain the following conceptual code (incrementing a value in the cache). My_Object obj = cache.get(key); obj.increment_value(); cache.put(key, obj); If this code is executed concurrently from more than one thread, there is a risk for inconsistency, as the new/incremented value may overwrite a cached value which is already different than it was at the time of the cache.get(). If so, should such code be synchronized (use some sort of lock)? Thanks, Ari Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE Actimize. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE Actimize may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
