Strange read-through operation after entry processor work

Question

Hi.
We use the combination cache listener - entry processor to do some actions when the data comes to coherence. We use Oracle Coherence Version 3.5.3/465.
Just after the entry processor has set the new value for the entry, the new "get" operation is called for the cache and jdbc hit is done for this key.
Here is the entry processor:
public Object process(Entry entry) {       
        if (!entry.isPresent()) {
            // No entities exist for this CoreMatchingString - creating new Matching unit
            MatchingUnit newUnit = new MatchingUnit(newTrade);
            entry.setValue(newUnit, true);
            return null;
        ((MatchingUnit)entry.getValue()).processMatching(newTrade);
        return null;
    }Very interesting, that if I use entry.setValue(value) without second parameter - I recieve the db hit just on setValue method. According to docs, setValue() with one parameter returns the previous value and its logical, that the cache hit (and therefore the db hit) is done just on set. But I use the overloaded version void setValue(java.lang.Object oValue, boolean fSynthetic), which is said to be light and should not fetch previous version of the object. But this is done anyway! Not on setValue itself, but just after the process() method called.
Actually it's strange, that coherence tries to fetch the previous value in the case it didn't exist! The cache.invoke(matchingStr, new CCPEntryProcessor(ccp)) is invoked on not existing record and it is created just on invokation. May be it's the bug or the place for optimization.
Thanks

Answer 1

bitec wrote:
Thanks, Robert, for such detailed answer.
Still not clear for me, why synthetic inserts are debatable. There are lots of cases, when the client simply updates/inserts the record (using setValue()) and does not need to recieve the previous value. If he needs, he will launch the method:Hi Anton,
it is debatable because the purpose of the fSynthetic flag is NOT so that you can optimize a cache store operation away. Synthetic event means that this is not real change in the data set triggered by the user, it is something Coherence has done on the backing map / on the cache for its own reasons and decisions to be able to provide high-availability to the data, and it only changes that particular Coherence node's subset of data but does not have a meaning related to the actually existing full data set. Such reasons are partition movement and cache eviction (or possibly any other reasons why Coherence would want to change the content of the backing map without telling the user that anything has changed).
If you set the synthetic flag, you are trying to masquerade a real data change as an event which Coherence decided to trigger. This is why it is debatable. Also, synthetic backing map events may not always lead to dispatching cache events (for partition rebalance they definitely not). This optimization may also be extended to synthetic cache events.
java.lang.Object setValue(java.lang.Object oValue)and recieve the previous value. If he doesn't, he calls:
void setValue(java.lang.Object oValue, boolean fSynthetic)and DOESN'T recieve the previous value as method is marked void. Thus he cannot get the previous value anyhow using this API, except of the direct manual db call. Yep, because Coherence is not interested in the old value in case of a synthetic event. The synthetic methods exist so that some entry can be changed in Coherence (usually by Coherence itself) in a way that it indicates a synthetic event so that listeners are not notified.
Some valid uses for such functionality for setValue invoked by user code could be compacting some cached value and replacing the value the backing map stores with the compacted representation, which does not mean a change in the meaning of the actual cached value, only the representation changes. Of course if the setValue(2) method does not actually honor the synthetic flag, then such functionality will still incur all the costs of a normal setValue(1) call.
But the previous value is anyway fetched by Coherence itself just after process() and client anyway doesn't get it! But any listeners on the cache may need to get it due to cache semantics reasons.
In this case I regard this as the bug, cause the client, which uses this API doesn't expect the cache hit to take place (no return value for this overloaded setValue() method), but it takes and leads to some extra problems, resulting from read-through mechanizm.
I would not regard it as a bug, it is probably the case of documenting a possible optimization too early, when it ultimately did not get implemented. I definitely would not try to abuse it to set a value without triggering a db fetch, as again, the intention of the synthetic flag is related not only to the cache loader functionality, but also to events and marking that a change indicates a real data change or a Coherence data management action.
Now I understand why coherence does not know, whether this is inserted or updated value, thanks for details.
Anton.
*Edited: I thought about this problem from the point of the oracle user, but may be this additional hit is necessary for event producers, which need to make the events, containing old/new values. In this case this seems to be the correct behaviour.... Seems that I need some other workaround to avoid db hit. The best workaround is the empty load() method for cachestore...You can try to find a workaround, but it is an ugly can of worms, because of the scenario when more than one thread tries to load the same entry, and some of them try to load it with a reason.
You may try to put some data into thread-local to indicate that you don't really want to load that particular key. The problem is that depending on configuration and race conditions your cache loader may not be called to clean up that thread-local as some other thread may just be invoked right now and in that case its return value is going to be returned to all other threads, too, so you may end up with a polluted thread.
Best regards,
Robert
Edited by: robvarga on Oct 15, 2010 4:25 PM