-
-
Notifications
You must be signed in to change notification settings - Fork 137
Connection Pool
A connection pool is used for two reasons:
- Reusing connections - Since the overhead of initiating a connection to the database is high (handshake etc'), connection pools allow keeping connections alive thus reducing that overhead.
- Limiting resources - Creating a DB connection per user request can be overwhelming to the DB. The pool used as a barrier, limiting the number of max connections.
There are many implementations of connection pool for JDBC. However, we can not use those in an async driver since we except not to block a thread when a connection is not available, but get a Future
that will be completed when the connection is ready.
ConnectionPool
is implementing the Connection
interface for convenience, allows using it just as one would use a regular connection. Behind the scene ConnectionPool
uses ObjectPool
to keep connections.
The object pool is implemented using actors in ActorBasedConnectionPool
- a new implementation of object pool based on an Actor. This is a new implementation that wasn't on the original lib and fixes various bugs. More info about the implementation here: https://medium.freecodecamp.org/how-to-implement-an-object-pool-with-an-actor-in-kotlin-ed06d3ba6257
Main classes in the API:
-
AsyncObjectPool
interface. -
ConnectionPool
implementation which works withActorBasedAsyncObjectPool
. -
PoolConfiguration
- hold the part of the configuration specific to the pool. -
ObjectFactory
- interface responsible to create/validate/destroy actual connections. There are 2 implementations:MySQLConnectionFactory
andPostgreSQLConnectionFactory
.