There is only one HConnection per cluster. Every phoenix connection to a cluster shares the same underlying HConnection. See ConnectionQueryServicesImpl#init() where we make sure that there is only one HConnection to the cluster. The HConnection is established when it's the first time that the phoenix driver tries to connect to the cluster.
On Tuesday, January 13, 2015, Nick Dimiduk <email@example.com> wrote:At least on Master, it appears the default HConnectionFactoryImpl is calling HConnectionManager.createConnection(Configuration), which creates an unmanaged connection. This means that each PhoenixConnection will be making and managing its own HBase Connection.On Tue, Jan 13, 2015 at 1:50 AM, Gabriel Reid <firstname.lastname@example.org> wrote:Hi David,
The PhoenixConnection class is not thread-safe, and shouldn't be
shared over multiple threads. I think that this is probably the case
with quite a few other JDBC drivers as well, so it's generally safer
to use a JDBC connection pool if you want to use connections in
If I remember correctly, a single HConnection is used (and shared) by
multiple PhoenixConnection objects that have been instantiated from
the same Driver instance, so there shouldn't be any performance
overhead to using a single Phoenix connection per thread.
On Tue, Jan 13, 2015 at 10:31 AM, David chen <email@example.com> wrote:
> My application will base on Phoenix, and response the multi-user query. I
> plan to create a thread pool that its per thread will correspond to a user
> query. But i don't sure whether or not multi-thread in the pool should share
> the single PhoenixConnection object?
> I remember that HBase community advice that the multi-thread should share
> the single HConnection object as much as possible.
> Any ideas can be appreciated!