nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Bende <bbe...@gmail.com>
Subject Re: Revision Source for AtomicDistributedMapCacheClient
Date Tue, 19 Nov 2019 14:13:35 GMT
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 <sweeks@weeksconsulting.us> 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

Mime
View raw message