poolboy Documentation

To create a worker compatible with Poolboy, your module should implement the poolboy_worker behavior (or simply be a gen_server that accepts arguments in start_link/1).

Key requirements:

1. start_link(Args): Must accept a list of arguments used to initialize the worker (e.g., connection strings).
2. init(Args): Should use process_flag(trap_exit, true) to ensure the worker can handle supervisor shutdowns gracefully.
3. Cleanup: Implement terminate/2 to close any resources (like database connections) held by the worker.

-module(my_worker).
-behaviour(gen_server).
-behaviour(poolboy_worker).

start_link(Args) ->
    gen_server:start_link(?MODULE, Args, []).

init(Args) ->
    process_flag(trap_exit, true),
    % ... initialization logic ...
    {ok, #state{...}}.

terminate(_Reason, #state{conn=Conn}) ->
    % ... cleanup logic ...
    ok.

You can manually manage worker lifecycle by checking out a worker from a named pool, performing a task, and then checking the worker back in. This is useful for low-level control over worker usage.

1. Use poolboy:checkout(PoolName) to get a worker PID.
2. Use the worker PID (typically via gen_server:call/2) to perform your task.
3. Use poolboy:checkin(PoolName, Worker) to return the worker to the pool.

To integrate Poolboy into an Erlang application (e.g., within a supervisor's init/1 function), use poolboy:child_spec/3. This function generates a child specification that can be used by a supervisor to manage the pool.

poolboy:child_spec(Name, PoolArgs, WorkerArgs)

• Name: The name of the pool.
• PoolArgs: A list of arguments for the pool configuration (e.g., worker_module, size, max_overflow).
• WorkerArgs: A list of arguments passed to the worker's start_link/1 function during initialization.

When defining a pool via poolboy:child_spec/3, you can provide the following configuration options in the PoolArgs list: