I don't think this has made it into the manual yet. You should definitely do so.
Thanks, Adam On Wed, Dec 21, 2011 at 2:16 PM, Aaron Cordova <[email protected]> wrote: > Thanks. > > What you have chosen seems like the best policy, favoring scalability over > atomic row operations, since this allows fairly common table designs that > have large rows to avoid running into memory issues. However, since it's a > departure from what appears to be the default in BigTable (and probably > Hbase as well) the manual should probably point that out, right next to the > section that outlines enabling isolation if required. > > Should I add a discussion to that effect in the 1.4 manual or has that > already been done? > > > On Dec 21, 2011, at 2:05 PM, Keith Turner wrote: > > > Yes. Regular scanners do provide a consistent state when there are no > > failures, if you call enableIsolation(). > > > > In the case of tablet server failures you can use the IsolatedScanner > > or handle the IsolationException yourself. If you need to handle rows > > that do not fit in memory, then you can pass a user defined buffer to > > the IsolatedScanner. This user defined buffer could buffer to disk. > > The default buffer just buffers rows in memory. > > > > BTW there is also a simple isolation example. > >
