anuengineer commented on a change in pull request #798: HDDS-1499. OzoneManager Cache. URL: https://github.com/apache/hadoop/pull/798#discussion_r282167175
########## File path: hadoop-hdds/common/src/main/java/org/apache/hadoop/utils/db/TypedTable.java ########## @@ -71,6 +96,27 @@ public boolean isEmpty() throws IOException { @Override public VALUE get(KEY key) throws IOException { + // Here the metadata lock will guarantee that cache is not updated for same + // key during get key. + if (cache != null) { + CacheValue<VALUE> cacheValue = cache.get(new CacheKey<>(key)); + if (cacheValue == null) { + return getFromTable(key); + } else { + // Doing this because, if the Cache Value Last operation is deleted + // means it will eventually removed from DB. So, we should return null. + if (cacheValue.getLastOperation() != CacheValue.OperationType.DELETED) { Review comment: Why do we even cache the deleted Operations? Delete is not in the performance critical path at all. If you can instruct the system to make the full commit or flush the buffer when there is a delete op you don't need to keep this extra state in the cache. yes, repeated deletes will call state machine call back. When do we actually flush / clear this entry? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org