Comparison
Connection poolvsObject pool
Connection pool
you reuse a fixed set of open database connections instead of paying the handshake on every query.
A cache of established connections shared by application threads. It removes per-request connection setup and, more importantly, bounds how many connections you can throw at the database. Pool size is a capacity decision on the database's behalf: too many and you overwhelm it, too few and requests queue in the application where you may not be measuring.
Full entry →Object pool
the object is not created and destroyed, it is borrowed and given back, and forgetting to give it back exhausts everything.
Keeping a set of expensive-to-create objects alive and lending them out, instead of constructing one per use. It is the right answer for things whose cost is a handshake rather than an allocation — connections, threads, large buffers — and almost always the wrong answer for plain objects in a language with a generational collector. Its two characteristic bugs are leaked handles that never return and state left over from the previous borrower.
Full entry →