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.
