-
-
Notifications
You must be signed in to change notification settings - Fork 139
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:
-
AsyncObjectPoolinterface. -
ConnectionPoolimplementation 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:MySQLConnectionFactoryandPostgreSQLConnectionFactory.