On Tue, Jan 13, 2015 at 11:28 AM, Samarth Jain <samarth.j...@gmail.com> wrote:
> 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. I see now. Thank you for clarifying. On Tuesday, January 13, 2015, Nick Dimiduk <ndimi...@gmail.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 <gabriel.r...@gmail.com> >> 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 >>> multiple threads. >>> >>> 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. >>> >>> - Gabriel >>> >>> >>> On Tue, Jan 13, 2015 at 10:31 AM, David chen <c77...@163.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! >>> >> >>
