Thanks I realized this morning that it's up to the AtomicDistributedMapCache implementation to manage the revision not whatever it's using it. I'm going to just have an integer column and +1 the revision during a replace if the current revision matches the one already stored in the entry.
Thansk On 11/19/19, 8:13 AM, "Bryan Bende" <[email protected]> wrote: 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
