I don't understand why HBASE-15600 is needed if we're ok with the local index updates not being transactional with older versions of HBase. Why can't we do the htable.batch() call in ParallelWriterIndexCommitter as we do now? The row keys are different. If this is an issue, then we could just enqueue the mutations and let them be submitted outside the row lock. We don't need to have the row lock.
Seems to me that it could be made to work without the branches diverging so radically. Thanks, James On Tuesday, June 7, 2016, rajeshb...@apache.org <chrajeshbab...@gmail.com> wrote: > Hi Team, > > As you know prior to PHOENIX-1734 we are storing all local index data in > separate table and colocate data and index regions. To ensure proper > colocation we need customer balancer, custom split and merge logic still > these will not ensure 100% colocation. That's why we started working > PHOENIX-1734 to store local index data in separate column families in the > same table to ensure 100% colocation. > > As part of PHOENIX-1734 we need to write local index udpates to same region > in preBatchMutate. When I am working with master branch(The HBase version > is 1.2.x) it went smooth and I continued the development and ensure new > implementation of local index works properly and committed the patch to > master branch as well. > > But when I started porting it to other branches(HBase versions less than > 1.2) I realized that write to same region is in preBatchMutate is not > allowed by HBase versions less than 1.2. There is a dependency of > HBASE-15600 to make the new local index implementation work properly for > versions less than 1.2. So I am not able to port it to other branches. I > will complete it once the next HBase point releases have HBASE-15600. > > Now code in master branch is not in sync with other branches but the local > indexing feature is much more stable in master branch after PHOENIX-1734 so > I think it would be better to have PHOENIX-1734 in master branch even > porting it to other branches might delay till upcoming HBase releases > available. > > Wdyt? > > Thanks, > Rajeshbabu. >
