Re: EntryProcessor and Locks
1. Correct. 2. Correct. 3. Data still can be serialized/deserialized because Ignite stores everything in binary form. However, operations will be executed locally. 4. It basically tells that if you execute a transaction within an affinityCall, and this transaction only includes entries that belong to same partition you collocated with, the whole process will be optimized to 1-phase-commit and will be local to this node. -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16410.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
Can you please confirm the below? 1. Affinity call or for that matter call does not lock any cache entry. 2. It runs on the primary node of the partition holding the cache entry 3. Does not serialize any operation either locally or across the cluster 4. Why does the ignite docs mention about 1 phase commit with affinity call? Is there still some serialization going on? https://apacheignite.readme.io/docs/affinity-collocation#collocating-compute-with-data affinityRun(...) and affinityCall(...), on the other hand, do not hold any locks. For example, it is absolutely legal to start multiple transactions or execute cache queries from these methods without worrying about deadlocks. In this case Ignite will automatically detect that the processing is collocated and will employ a light-weight 1-Phase-Commit optimization for transactions (instead of 2-Phase-Commit). yakov wrote > Entry processor will always be executed inside java-level synchronized > section. Moreover, cache requests of the kind are processed inside striped > pool and therefore will be executed sequentially. > > If your entry processor has a high chance to be readonly then you can > think of switching to IgniteCompute.affinityCall() and returning partial > result from the callable. Will that work? > > Yakov yakov wrote > Entry processor will always be executed inside java-level synchronized > section. Moreover, cache requests of the kind are processed inside striped > pool and therefore will be executed sequentially. > > If your entry processor has a high chance to be readonly then you can > think of switching to IgniteCompute.affinityCall() and returning partial > result from the callable. Will that work? > > Yakov yakov wrote > Entry processor will always be executed inside java-level synchronized > section. Moreover, cache requests of the kind are processed inside striped > pool and therefore will be executed sequentially. > > If your entry processor has a high chance to be readonly then you can > think of switching to IgniteCompute.affinityCall() and returning partial > result from the callable. Will that work? > > Yakov -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16389.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
I read the IgniteCompute API. Does it support affinityCall multiple keys at the same time? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16381.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
Hi Yakav, Our requirement is to just be able to read partial content of large cache items without any concurreny overhead. read committed guarantees are good enough. Are you saying the suggestion from afedotov (use entry processor within an optimistic, read committed transaction) will still serialize the entry processor invokes? We already built a good bit of our API based on that premise. If yes :( , how can you access your ignite cache from within IgniteCompute.affinityCall() ? thanks, Rajeev -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16379.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
Entry processor will always be executed inside java-level synchronized section. Moreover, cache requests of the kind are processed inside striped pool and therefore will be executed sequentially. If your entry processor has a high chance to be readonly then you can think of switching to IgniteCompute.affinityCall() and returning partial result from the callable. Will that work? Yakov -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16378.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
Hi, It depends on the isolation level you specify for the OPTIMISTIC transaction. Please check https://apacheignite.readme.io/docs/transactions#section-optimistic-transactions Kind regards, Alex. On Tue, Aug 15, 2017 at 2:31 AM, rajivgandhi [via Apache Ignite Users] < ml+s70518n16185...@n6.nabble.com> wrote: > What will happen for the reads when there is a concurrent write by some > other process? > > Will we see OptimisticTransactionException or will be get stale reads > (preferred in out use case). > > thanks! > > > -- > If you reply to this email, your message will be added to the discussion > below: > http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks- > tp16150p16185.html > To start a new topic under Apache Ignite Users, email > ml+s70518n1...@n6.nabble.com > To unsubscribe from Apache Ignite Users, click here > <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=YWxleGFuZGVyLmZlZG90b2ZmQGdtYWlsLmNvbXwxfC0xMzYxNTU0NTg=> > . > NAML > <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16203.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
What will happen for the reads when there is a concurrent write by some other process? Will we see OptimisticTransactionException or will be get stale reads (preferred in out use case). thanks! -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16185.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
HI, Yes, I meant starting a transaction via igniteInstance.transactions().txStart(OPTIMISTIC, isolationLevel) and calling cache.invoke(key, entryProcessor) within its scope. Kind regards, Alex. On Mon, Aug 14, 2017 at 7:59 PM, rajivgandhi [via Apache Ignite Users] < ml+s70518n16172...@n6.nabble.com> wrote: > By the way, I requested subscribe several times. > > The one thing with subscription is that it floods my email box with > messages from other threads as well. > > -- > If you reply to this email, your message will be added to the discussion > below: > http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks- > tp16150p16172.html > To start a new topic under Apache Ignite Users, email > ml+s70518n1...@n6.nabble.com > To unsubscribe from Apache Ignite Users, click here > <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=YWxleGFuZGVyLmZlZG90b2ZmQGdtYWlsLmNvbXwxfC0xMzYxNTU0NTg=> > . > NAML > <http://apache-ignite-users.70518.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16175.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
By the way, I requested subscribe several times. The one thing with subscription is that it floods my email box with messages from other threads as well. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16172.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
Thanks. How do you use optimistic tx with Entry processor? The ConcurrencyMode and isolationMode can only be set when you start a tx. Are you saying we should call the entry processor within a tx with concurencymode Optimistic? thanks ! -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16171.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: EntryProcessor and Locks
Hi, Looks like you are not subscribed to the mailing list. Please make sure you are subscribed <http://apache-ignite-users.70518.x6.nabble.com/mailing_list/MailingListOptions.jtp?forum=1> . Answering to your questions, with the PESSIMISTIC or implicit transactions EntryProcessor will cause a lock on a key, thus making one of the threads waiting on another. Probably, you should consider the OPTIMISTIC <https://apacheignite.readme.io/docs/transactions#section-optimistic-transactions> mode. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16169.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
