Hi Chen, The per-table lock protects the tables from concurrent accesses/modifications. The table references are shared across all the threads that execute DDL/DML operations in the catalog. The catalog_ lock protects the entire catalog and shouldn't be held for long running operations. The catalog_ lock is only acquired when we want to get a new catalog version and it is then released to allow for other concurrent operations to make progress. What protects the table modifications is the synchronized blocks that use the table references for locks.
Hope that helps. Dimitris On Tue, May 3, 2016 at 10:27 AM, Tim Armstrong <[email protected]> wrote: > Hi Chen, > Objects in Java are assigned by reference so they should all be > referencing the same underlying object (i.e. there aren't separate local > copies). I don't think getExistingTable() copies the object. > > I'm not especially familiar with the catalog's locking scheme, but it > doesn't look like it holds the global catalog lock for the whole table > operation - it unlocks the catalog lock before making most of the table > modifications. > > - Tim > > On Tue, May 3, 2016 at 10:14 AM, Chen Huang <[email protected]> wrote: > > > Hi, > > > > I saw we are doing some synchronization in CatalogOpExecutor: > > > > > https://github.com/cloudera/Impala/blob/cdh5-trunk/fe/src/main/java/com/cloudera/impala/service/CatalogOpExecutor.java#L337 > > > > Can anybody help me understand what the effect of synchronizing on a > > method-local variable tbl? > > - Doesn't each thread get its own copy of tbl, which is just a reference > to > > the actual table object and thus end up synchronize with only itself > since > > no other threads can ever share the same local copy of tbl? > > - Isn't the lock on catalog_ already doing the global synchronization? > Why > > do we need another synchronization on tbl? > > > > Thanks, > > Chen > > >
