Each region is a little separate key value store, moving among the RegionServer containers. If you are observing a region then your observer must be tied to the region lifecycle, or otherwise at any moment what was formerly an all-in-process extension to functionality on a region is now distributed, with all the inherent complications. Does that make sense? And would we hide that from the coprocessor implementor somehow? Shouldn't the observer, being intimate with region details, be managed equivalently to the region? In my opinion: no, no, and yes.
Late in 0.94 and on trunk we did introduce a RegionServer singleton observer but that currently only manages one upcall for server level state. It could be a place for a singleton observer for every action on the server, but full duplication of the region level API there would be confusing I think, and (re)loading an implementation on only one table would be impossible of course. On Wed, Jul 24, 2013 at 10:34 PM, lars hofhansl <la...@apache.org> wrote: > It's because a region is the independent unit in HBase. A region is > mobile. If you pick something larger than a region you are tying state > together that would complicate region mobility. > > There are probably other ways to design this, but from this angle it makes > sense. > If Andy Purtell is around he probably can elaborate further. > > -- Lars > > ________________________________ > From: Vladimir Rodionov <vrodio...@carrieriq.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl < > la...@apache.org> > Sent: Wednesday, July 24, 2013 10:19 PM > Subject: RE: Couple notes and questions on RegionObserver's > > > Lars, I know that coprocessors are per region, I just do not understand > why: > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
