You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by ka...@barclays.com on 2015/12/15 23:10:04 UTC
Phoenix JDBC connection pool
Hi,
Should we pool the Phoenix JDBC connection like any other JDBC connection (probably using DBCP or similar)? If not:
1. What's the reason behind not to pool?
2. What should be the access pattern?
a. Create the connection once and use the cached connection till the process restarts - Possibly with some check on every usage to make sure it's still valid? (what if the Hbase cluster gets restarted during middle of the day, will the connections become stale?)
b. Create the connection on need basis - What will be the performance impact of creating connection every time?
Please can you clarify? I tried searching for this and all I see is "Shouldn't pool the connections" without any explanation.
Thanks
Kannan.
_______________________________________________
This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer.
For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.
_______________________________________________
Re: Phoenix JDBC connection pool
Posted by Josh Elser <jo...@gmail.com>.
Created https://issues.apache.org/jira/browse/PHOENIX-2539
James Taylor wrote:
> Another good contribution would be to add this question to our FAQ.
>
> On Tue, Dec 15, 2015 at 2:20 PM, Samarth Jain <samarth@apache.org
> <ma...@apache.org>> wrote:
>
> Kannan,
>
> See my response here:
> https://mail-archives.apache.org/mod_mbox/phoenix-user/201509.mbox/%3CCAMfSBK+WKzd5EscXLJcn9nVpDYd66dH=nL=dEVdc9N_SkWWufg@mail.gmail.com%3E
>
> There is a JIRA in place
> https://issues.apache.org/jira/browse/PHOENIX-2388 to help pooling
> of phoenix connections. Would be a good one to contribute.
>
> - Samarth
>
>
>
> On Tue, Dec 15, 2015 at 2:10 PM, <kannan.ramanathan@barclays.com
> <ma...@barclays.com>> wrote:
>
> Hi,____
>
> __ __
>
> Should we pool the Phoenix JDBC connection like any other JDBC
> connection (probably using DBCP or similar)? If not:____
>
> __ __
>
> __1.__What’s the reason behind not to pool?____
>
> __2.__What should be the access pattern?____
>
> __a.__Create the connection once and use the cached connection
> till the process restarts - Possibly with some check on every
> usage to make sure it’s still valid? (what if the Hbase cluster
> gets restarted during middle of the day, will the connections
> become stale?)____
>
> __b.__Create the connection on need basis - What will be the
> performance impact of creating connection every time?____
>
> __ __
>
> Please can you clarify? I tried searching for this and all I see
> is “Shouldn’t pool the connections” without any explanation.____
>
> __ __
>
> Thanks____
>
> Kannan.____
>
> _______________________________________________
>
> This message is for information purposes only, it is not a
> recommendation, advice, offer or solicitation to buy or sell a
> product or service nor an official confirmation of any
> transaction. It is directed at persons who are professionals and
> is not intended for retail customer use. Intended for recipient
> only. This message is subject to the terms at:
> www.barclays.com/emaildisclaimer
> <http://www.barclays.com/emaildisclaimer>.
>
> For important disclosures, please see:
> www.barclays.com/salesandtradingdisclaimer
> <http://www.barclays.com/salesandtradingdisclaimer> regarding
> market commentary from Barclays Sales and/or Trading, who are
> active market participants; and in respect of Barclays Research,
> including disclosures relating to specific issuers, please see
> http://publicresearch.barclays.com.
>
> _______________________________________________
>
>
>
Re: Phoenix JDBC connection pool
Posted by James Taylor <ja...@apache.org>.
Another good contribution would be to add this question to our FAQ.
On Tue, Dec 15, 2015 at 2:20 PM, Samarth Jain <sa...@apache.org> wrote:
> Kannan,
>
> See my response here:
>
> https://mail-archives.apache.org/mod_mbox/phoenix-user/201509.mbox/%3CCAMfSBK+WKzd5EscXLJcn9nVpDYd66dH=nL=dEVdc9N_SkWWufg@mail.gmail.com%3E
>
> There is a JIRA in place
> https://issues.apache.org/jira/browse/PHOENIX-2388 to help pooling of
> phoenix connections. Would be a good one to contribute.
>
> - Samarth
>
>
>
> On Tue, Dec 15, 2015 at 2:10 PM, <ka...@barclays.com> wrote:
>
>> Hi,
>>
>>
>>
>> Should we pool the Phoenix JDBC connection like any other JDBC connection
>> (probably using DBCP or similar)? If not:
>>
>>
>>
>> 1. What’s the reason behind not to pool?
>>
>> 2. What should be the access pattern?
>>
>> a. Create the connection once and use the cached connection till
>> the process restarts - Possibly with some check on every usage to make sure
>> it’s still valid? (what if the Hbase cluster gets restarted during middle
>> of the day, will the connections become stale?)
>>
>> b. Create the connection on need basis - What will be the
>> performance impact of creating connection every time?
>>
>>
>>
>> Please can you clarify? I tried searching for this and all I see is
>> “Shouldn’t pool the connections” without any explanation.
>>
>>
>>
>> Thanks
>>
>> Kannan.
>>
>> _______________________________________________
>>
>> This message is for information purposes only, it is not a
>> recommendation, advice, offer or solicitation to buy or sell a product or
>> service nor an official confirmation of any transaction. It is directed at
>> persons who are professionals and is not intended for retail customer use.
>> Intended for recipient only. This message is subject to the terms at:
>> www.barclays.com/emaildisclaimer.
>>
>> For important disclosures, please see:
>> www.barclays.com/salesandtradingdisclaimer regarding market commentary
>> from Barclays Sales and/or Trading, who are active market participants; and
>> in respect of Barclays Research, including disclosures relating to specific
>> issuers, please see http://publicresearch.barclays.com.
>>
>> _______________________________________________
>>
>
>
Re: Phoenix JDBC connection pool
Posted by Samarth Jain <sa...@apache.org>.
Kannan,
See my response here:
https://mail-archives.apache.org/mod_mbox/phoenix-user/201509.mbox/%3CCAMfSBK+WKzd5EscXLJcn9nVpDYd66dH=nL=dEVdc9N_SkWWufg@mail.gmail.com%3E
There is a JIRA in place https://issues.apache.org/jira/browse/PHOENIX-2388
to help pooling of phoenix connections. Would be a good one to contribute.
- Samarth
On Tue, Dec 15, 2015 at 2:10 PM, <ka...@barclays.com> wrote:
> Hi,
>
>
>
> Should we pool the Phoenix JDBC connection like any other JDBC connection
> (probably using DBCP or similar)? If not:
>
>
>
> 1. What’s the reason behind not to pool?
>
> 2. What should be the access pattern?
>
> a. Create the connection once and use the cached connection till
> the process restarts - Possibly with some check on every usage to make sure
> it’s still valid? (what if the Hbase cluster gets restarted during middle
> of the day, will the connections become stale?)
>
> b. Create the connection on need basis - What will be the
> performance impact of creating connection every time?
>
>
>
> Please can you clarify? I tried searching for this and all I see is
> “Shouldn’t pool the connections” without any explanation.
>
>
>
> Thanks
>
> Kannan.
>
> _______________________________________________
>
> This message is for information purposes only, it is not a recommendation,
> advice, offer or solicitation to buy or sell a product or service nor an
> official confirmation of any transaction. It is directed at persons who are
> professionals and is not intended for retail customer use. Intended for
> recipient only. This message is subject to the terms at:
> www.barclays.com/emaildisclaimer.
>
> For important disclosures, please see:
> www.barclays.com/salesandtradingdisclaimer regarding market commentary
> from Barclays Sales and/or Trading, who are active market participants; and
> in respect of Barclays Research, including disclosures relating to specific
> issuers, please see http://publicresearch.barclays.com.
>
> _______________________________________________
>