Below sounds good. There is a tmp dir under each region. That is probably better place to do the messing. St.Ack
On Sat, Sep 10, 2011 at 3:10 PM, Ted Yu <[email protected]> wrote: > 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 >> > >> >
