[
https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108950#comment-14108950
]
Nicolas Liochon commented on HBASE-10602:
-----------------------------------------
bq. where does the ~100k objects # come from btw?),
Just that you can do 100k of puts per second with HBase :-)
bq. Wouldn't you want the async call to be the new signature, so it doesn't
break backwards compatibility?
Yes, agreed.
One of the questions not clear to me is batch async and batch streaming. I'm
not sure I don't prefer a callback mechanism for them (if you batch multiple
operations, they can come back in any order, so the most efficient solution
client side is to get the result as it's executed.
bq. This also means that you can grow/evolve the Table interface rather than
figuring out the future/async version in the first iteration.
Agreed it's the right approach.
> 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)
