We should also protect the HTableDescriptor in memory against possible failure.
How about: 1. Create new HTableDescriptor, htd1, whose storage is under /tmp on hdfs and is a clone of original HTableDescriptor, htd 2. Perform series of modifications on htd1 3. Assuming there is no error, copy contents of htd1 onto htd and rename the file under /tmp as Michael suggested. 4. If there was error, report back the exception and skip step 3 above It seems we need more helper methods in HTableDescriptor to fulfill the above. Cheers On Sat, Sep 10, 2011 at 2:33 PM, Stack <[email protected]> wrote: > Its as though we should do all the mods in a tmp dir and then if all > go through, only then do fs.rename moving the new schema into place. > > St.Ack > > On Fri, Sep 9, 2011 at 7:25 PM, Ted Yu <[email protected]> wrote: > > I ran unit tests for HBASE-4358 patch 3 and they passed. > > > > The only issue remaining is in TableMultiFamilyHandler.java > > @Override > > protected void updateTableDescriptor(HTableDescriptor desc) > > throws IOException { > > // just ask all of the sub-operations to update the descriptor > > for (TableFamilyHandler op : operations) { > > op.updateTableDescriptor(desc); > > } > > } > > where we don't have ACID guarantee that either all modifications go > through > > or none of the modifications go through. > > > > If the above is Okay, I can add javadoc for the above at time of commit. > > > > If anyone thinks this is not good, please comment on ways of supporting > ACID > > guarantee. > > > > Thanks > > >
