11 Replies Latest reply: Oct 18, 2012 7:41 AM by robvarga RSS

    implicit locking by EntryProcessor block NamedCache.get() operation

    925966
      Hi,

      I am new to Coherence, just want to know whether implicit locking by EntryProcessor block NamedCache.get() operation? Thanks.

      Henry
        • 1. Re: implicit locking by EntryProcessor block NamedCache.get() operation
          user738616
          Hi Henry,

          Yes it will block the get() operation because a get() can trigger load() if you are using RWBM. But, filters and aggregators are read-only operations and will not be blocked that you may use if this is your concern.

          Hope this helps!

          Cheers,
          NJ
          • 2. Re: implicit locking by EntryProcessor block NamedCache.get() operation
            ivan.cikic
            Hi NJ,
            user738616 wrote:
            But, filters and aggregators are read-only operations and will not be blocked that you may use if this is your concern.
            is this true only if you have daemon threads defined for particular cache service, or it applies always?

            Thanks,
            Ivan
            • 3. Re: implicit locking by EntryProcessor block NamedCache.get() operation
              user738616
              Hi Ivan,

              It will only apply if a thread pool is configured for the service.

              Hope this helps!

              Cheers,
              NJ
              • 4. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                925966
                Hi NJ,

                So you mean an entry being implicitly locked by EntryProcessor can still be captured if it match a filter? And that will be aggregated in an aggregator?

                thanks,
                Henry
                • 5. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                  user738616
                  Hi Henry,

                  Yes the entries will be aggregated even if the entries to be aggregated are locked by EP at that time.

                  Hope this helps!

                  Cheers,
                  NJ
                  • 6. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                    925966
                    Hi NJ,

                    Thanks for prompt response. Sorry for last question, so the value returned by filter or aggregated contains the original value(image before entering EP) rather than the value being updated within EP during the time,right?

                    Thanks,
                    Henry
                    • 7. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                      user738616
                      Hi Henry,

                      It will be the value that is present in the cache at the time of aggregation or filter. If the value is already updated in the cache by EP it will be the updated value (whatever is the value at the time of aggregation/filter in the cache). The Aggregator and Filter will not wait for the EP to complete.

                      Hope this helps!

                      Cheers,
                      NJ
                      • 8. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                        968687
                        Hi Thanks for your response to the above question, I was just curious to know what if we want the filter should not pick the Entries currently under process by the Entry Processor. My use case is as under there is a component adding Objects to Cache, we Invoke a ConditionalProcessor to update matching Entry, since this Cache is continuously increasing (Within Finite period and limit), we want to invoke the ConditionalProcessor again, In case to avoid the EntryProcessor processing a entry twice, what could be done, please provide your views on the same.
                        • 9. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                          user738616
                          Hi,

                          First of all, I don't think it is a good idea to run EPs one after the another without waiting for the current EP to finish. Anyways, the second EP will be not be able to update the entries until the first EP updations are complete. Also, I would suggest to reduce the data updated by the current EP using PartitionedFilter and increase the delay between EPs.

                          HTH

                          Cheers,
                          _NJ                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
                          • 10. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                            968687
                            Thanks NJ, it was quite helpful.
                            • 11. Re: implicit locking by EntryProcessor block NamedCache.get() operation
                              robvarga
                              965684 wrote:
                              Hi Thanks for your response to the above question, I was just curious to know what if we want the filter should not pick the Entries currently under process by the Entry Processor. My use case is as under there is a component adding Objects to Cache, we Invoke a ConditionalProcessor to update matching Entry, since this Cache is continuously increasing (Within Finite period and limit), we want to invoke the ConditionalProcessor again, In case to avoid the EntryProcessor processing a entry twice, what could be done, please provide your views on the same.
                              Hi,

                              When a concurrent change makes the entry to exit the filter result set is the simpler of the two race conditions, you can simply recheck the entry from the entry-processor whether it still matches the filter before applying a change to it.

                              There is another issue is when a concurrent change would make the entry to enter the filter result set. In this case an entry-processor would not have the chance to process that entry even though the concurrent change materialized after the filter finished but before the process part of the entry-processor started. In this case you simply need to interpret this situation that the concurrent change was actually slower and did not materialize before the EP ran. This may introduce some ordering and atomicity issues. If you need atomicity for filtering and entry-processing for such scenarios, you may need to handle your own "transactions" above changes in the cache, as atomicity across filter and process phase is equivalent to repeatable read isolation. David Whitmarsh had a presentation of a solution in this field in the Coherence SIGs: http://coherence.oracle.com/download/attachments/13173278/ShadowMVCCSIG.pdf

                              Best regards,

                              Robert