Bharath Vissapragada has posted comments on this change. Change subject: IMPALA-4449: Revisit table locking pattern in the catalog ......................................................................
Patch Set 3: (2 comments) http://gerrit.cloudera.org:8080/#/c/5710/3/fe/src/main/java/org/apache/impala/catalog/CatalogServiceCatalog.java File fe/src/main/java/org/apache/impala/catalog/CatalogServiceCatalog.java: Line 196: catalogLock_.writeLock().lock(); - The only pattern I see for taking this write lock seems to be to be to call incrementAndGetCatalogVersion() and then we immediately unlock() it.(Please correct me if I'm wrong). - If it is the only case, can we call incrementAndGetCatalogVersion() below and make this method return the new version? Something like tryLockTableAndGetNewVersion()? That prevents the callers from accidentally missing a catalogLock_.writeLock().unlock()? - That also addresses Marcel's comment about adding a Precondition check for each block. - Not totally sure if this is a good idea but wanted to put it up for discussion. http://gerrit.cloudera.org:8080/#/c/5710/3/fe/src/main/java/org/apache/impala/service/CatalogOpExecutor.java File fe/src/main/java/org/apache/impala/service/CatalogOpExecutor.java: Line 384: catalog_.getLock().writeLock().unlock(); We don't seem to be write-locking this after L378. Is this really required? -- To view, visit http://gerrit.cloudera.org:8080/5710 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: Id08e21da31deb1f003b3cada4517651f3b3b2bb2 Gerrit-PatchSet: 3 Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-Owner: Dimitris Tsirogiannis <dtsirogian...@cloudera.com> Gerrit-Reviewer: Alex Behm <alex.b...@cloudera.com> Gerrit-Reviewer: Bharath Vissapragada <bhara...@cloudera.com> Gerrit-Reviewer: Dan Hecht <dhe...@cloudera.com> Gerrit-Reviewer: Dimitris Tsirogiannis <dtsirogian...@cloudera.com> Gerrit-Reviewer: Marcel Kornacker <mar...@cloudera.com> Gerrit-HasComments: Yes
