phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "孟庆义(孟庆义)" <>
Subject inconsistent sequence number between server and client metadata cache
Date Mon, 11 Aug 2014 09:01:53 GMT
Hi, all :


I use phoenix 3.0 and here is what I found: 

Create a table T, then metadata cache has T

Create an index I on T, then metadata cache has I, but will trigger to
update T by following code in PMetadataImpl.addTable



if (parentTable != null) {

                List<PTable> oldIndexes = parentTable.getIndexes();

                List<PTable> newIndexes =
Lists.newArrayListWithExpectedSize(oldIndexes.size() + 1);


                if (oldTable != null) {




                parentTable = PTableImpl.makePTable(parentTable,
table.getTimeStamp(), newIndexes);

                tables.put(parentTable.getKey(), parentTable);





The method makePTable will increase T’s sequence number by 1. 



    public static PTableImpl makePTable(PTable table, long timeStamp,
List<PTable> indexes) throws SQLException {

        return new PTableImpl(

                table.getTenantId(), table.getSchemaName(),
table.getTableName(), table.getType(), table.getIndexState(), timeStamp, 

                table.getSequenceNumber() + 1, table.getPKName(),
table.getBucketNum(), getColumnsToClone(table), table.getParentTableName(),

                table.isImmutableRows(), table.getPhysicalNames(),
table.getDefaultFamilyName(), table.getViewStatement(),
table.isWALDisabled(), table.isMultiTenant(), table.getViewType(),



But during my debug the server side sequence number seem unchanged, and then
I made a “alter table T drop column”, there is a
ConcurrentMutationException thrown due to inconsistent sequence number.

I can see that the code catch the Exception and update table T with sever
side metadata, and then a retry complement the drop column operation. 

My question is why we increase the sequence number on client side in the
beginning? Which side is wrong, server or client?




  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message