There are two methods in AtomicDistributedMapCache, one is fetch which returns an AtomicCacheEntry which has <K,V,R>, the second is replace which takes an updated entry and will replace if the revision in the updated entry matches the revision stored in the cache (i.e. no one else has updated it).
In WaitNotifyProtocol, getSignal calls fetch and replace signal calls replace. For a relational database you will need some kind of revision column on the table, and typically you would issue an update statement with a where clause that has "REVISION = ?" and if no rows are updated from the statement then you know the revision no longer matches. Here is an example of how we implemented optimistic locking for registry which is similar: https://github.com/apache/nifi-registry/blob/master/nifi-registry-core/nifi-registry-revision/nifi-registry-revision-spring-jdbc/src/main/java/org/apache/nifi/registry/revision/jdbc/JdbcRevisionManager.java#L133-L148 On Tue, Nov 19, 2019 at 9:01 AM Shawn Weeks <[email protected]> wrote: > > Where does the value from revision come from on the call to replace in > AtomicDistributedMapCacheClient? What should it be set to on a call to > replace if a revision isn’t provided? I’m looking at the WaitNotifyProtocol > class and it looks like revision isn’t even used. If that’s the case then the > changes I did a while back to add support for AtomicDistributedMapCacheClient > to HBase doesn’t actually work with Wait Notify as the values in the call to > replace will never work. I think that means that Wait Notify isn’t updating > the cache in an atomic way either but I may be missing something. > > Thanks > Shawn
