This discussion is archived
11 Replies Latest reply: Oct 18, 2012 5:41 AM by robvarga RSS

implicit locking by EntryProcessor block NamedCache.get() operation

925966 Newbie
Currently Being Moderated
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 Pro
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Pro
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Pro
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Pro
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Pro
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    Thanks NJ, it was quite helpful.
  • 11. Re: implicit locking by EntryProcessor block NamedCache.get() operation
    robvarga Oracle ACE
    Currently Being Moderated
    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

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points