> >> What do you mean "after it ends"? > I meant when the client program finishes running without calling the > close function or the flushCommits.. Shouldn't commits be flushed when > Htable's finalize is called?
HTable has no finalize(). Correct me if I'm wrong, but isn't finalize() what is called by the garbage collector before an object is evicted? It seems very wrong for us to override that and flush the buffer in it, and bad practice to rely on a finalize() method to be automatically called (your code relies on GC timing?). You need to explicitly flush your buffer by either calling flushCommits() or close().... this seems normal and logical to me. Is there some reason you do not want to call close or flush? > >> Currently Delete operations are not buffered on the client side, > only Puts are. > Will this not lead to non-deterministic results for some cases? > Eg. Put, then a delete and then a put again on the same row key from > the same client.. Yes, but this seems like a strange use case. You want to put to a row, delete on that row, and then put to the same row, all without flushing to HBase? It seems to me that if your application does this from a single client, then this logic can be dealt with in the application rather than issuing a series of interleaved puts and deletes to HBase. Can you describe your use case?
