James Taylor commented on PHOENIX-2388:

A PhoenixConnection is meant to be lightweight enough to not require pooling. 
The underlying connection to the cluster (HConnection) is cached and shared 
across all PhoenixConnections for the same JVM (per cluster per principal). See 

If you wanted to pool them, you'd need to make sure you clear any state on them 
when they are put back into the pool:
- clear PMetaDataCache (client side cache)
- remove any SCN (which was set on URL or through Properties)
- remove the ConnectionQueryServices and re-instantiate (unless Properties and 
principal are the same)
- reset tenantId to null
- etc. - see member variables on PhoenixConnection

I'm not sure there'd be any perf gain, hence it's never been done. If you're 
finding it expensive to create a new PhoenixConnection, it'd be good to profile 
this and fix any bottlenecks in the code.

> Support pooling Phoenix connections
> -----------------------------------
>                 Key: PHOENIX-2388
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2388
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Priority: Major
>         Attachments: PHOENIX-2388.patch
> Frequently user are plugging Phoenix into an ecosystem that pools 
> connections. It would be possible to implement a pooling mechanism for 
> Phoenix by creating a delegate Connection that instantiates a new Phoenix 
> connection when retrieved from the pool and then closes the connection when 
> returning it to the pool.

This message was sent by Atlassian JIRA

Reply via email to