phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4025) Make CachingHTableFactory thread-safe for 0.98 branch
Date Fri, 14 Jul 2017 18:02:01 GMT

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

Andrew Purtell commented on PHOENIX-4025:
-----------------------------------------

Yes you can use the same pattern in 0.98 too - use the connection to get lightweight htable
instances with getTable(). There are some API naming differences (Connection -> HConnection
, ConnectionManager -> HConnectionManager) so minor fixups would be needed when backporting
to 0.98. Would not be a big deal. 

> Make CachingHTableFactory thread-safe for 0.98 branch
> -----------------------------------------------------
>
>                 Key: PHOENIX-4025
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4025
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.11.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>             Fix For: 4.12.0
>
>
> CachingHTableFactory, which is used in global index writes, isn't thread-safe (see discussion
in PHOENIX-4021) and will be removed in the master and 4.x-HBase-1.x branches. However, according
to PHOENIX-3159 it's still needed in HBase 0.98-based Phoenix because creating HTables is
still heavy-weight in 0.98. 
> This means it needs to be made thread-safe. Current plan is when an HTable's requested,
check the reference count (which is already tracked for cleanup purposes) and if the count
is 1, create a new HTable. We'll cache lists of identical HTables per HBase table, rather
than 1 HTable per HBase table. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message