Connection Pool with Erlang PB Client Necessary?

Andrew Berman rexxe98 at gmail.com
Mon Aug 15 03:24:14 EDT 2011


So I looked at a bunch of pooling applications and none of them really
have the functionality and flexibility I'm used to with Java
connection pools.  So, I created my own OTP pooling application,
Pooly.  It allows multiple pools to be configured, has flexibility on
configuring the pool (idle timeout, max age of processes, initial
count, acquire increment, max pool size, and min pool size) and
reduces the size of the pool based on the configuration parameters.

Feel free to check it out: https://github.com/aberman/pooly

--Andrew

On Tue, Jul 26, 2011 at 12:20 PM, Justin Sheehy <justin at basho.com> wrote:
> Yes, Andrew -- that is a fine approach to using a connection pool.
>
> Go for it.
>
> -Justin
>
>
>
> On Tue, Jul 26, 2011 at 3:18 PM, Andrew Berman <rexxe98 at gmail.com> wrote:
>> Thanks for all the replies guys!
>>
>> I just want to make sure I'm totally clear on this.  Bob's solution
>> would work well with my design.  So basically, this would be the
>> workflow?
>>
>> 1.  check out connection from the pool
>> 2.  set client id on connection (which would have some static and some
>> random component)
>> 3.  perform multiple operations (gets, puts, etc.) which would be seen
>> as a single "transaction"
>> 4.  check in the connection to the pool
>>
>> This way once the connection is checked out from the pool, if another
>> user comes along he cannot get that same connection until it has been
>> checked back in, which would meet Justin's requirements.  However,
>> each time it's checked out, a new client id is created.
>>
>> Does this sound reasonable and in line with proper client id usage?
>>
>> Thanks again!
>>
>> Andrew
>>
>>
>> On Tue, Jul 26, 2011 at 11:55 AM, Justin Sheehy <justin at basho.com> wrote:
>>> The simplest guidance on client IDs that I can give:
>>>
>>> If two mutation (PUT) operations could occur concurrently or without
>>> awareness of each other, then they should have different client IDs.
>>>
>>> As a result of the above: if you are sharing a connection, then you
>>> should use a different client ID for each separate user of that
>>> connection.
>>>
>>> -Justin
>>>
>>
>




More information about the riak-users mailing list