[jira] [Commented] (HBASE-10602) Cleanup HTable public interface

["Carter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14105437#comment-14105437 ] 

Carter commented on HBASE-10602:
--------------------------------

Wouldn't you want the async call to be the new signature, so it doesn't break backwards compatibility?  I guess it doesn't matter with "put", but for instance checkAndPut and other non-void methods:

{code}
public boolean checkAndPut(byte[], byte[], byte[], byte[], Put); 
public Future<Boolean> asyncCheckAndPut(byte[], byte[], byte[], byte[], Put); 
{code}

This also means that you can grow/evolve the Table interface rather than figuring out the future/async version in the first iteration.

Last point, following on Nick's assertion about object creation (where does the ~100k objects # come from btw?), you may not want to default the user to an async call creates more garbage collection in the client, rather let them decide if they need it.


> Cleanup HTable public interface
> -------------------------------
>
>                 Key: HBASE-10602
>                 URL: https://issues.apache.org/jira/browse/HBASE-10602
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client, Usability
>            Reporter: Nick Dimiduk
>            Assignee: Enis Soztutar
>            Priority: Blocker
>             Fix For: 0.99.0
>
>         Attachments: hbase-10602_v1.patch
>
>
> HBASE-6580 replaced the preferred means of HTableInterface acquisition to the HConnection#getTable factory methods. HBASE-9117 removes the HConnection cache, placing the burden of responsible connection cleanup on whomever acquires it.
> The remaining HTable constructors use a Connection instance and manage their own HConnection on the callers behalf. This is convenient but also a surprising source of poor performance for anyone accustomed to the previous connection caching behavior. I propose deprecating those remaining constructors for 0.98/0.96 and removing them for 1.0.
> While I'm at it, I suggest we pursue some API hygiene in general and convert HTable into an interface. I'm sure there are method overloads for accepting String/byte[]/TableName where just TableName is sufficient. Can that be done for 1.0 as well?



--
This message was sent by Atlassian JIRA
(v6.2#6252)