RFC Title
To be Reviewed By: 12/11/2019
Authors: Dan Smith
Status: Draft | Discussion | Active | Dropped | Superseded
Superseded by: N/A
Related:
- GEODE-7555Getting issue details... STATUS
Problem
Currently, users must use the static PoolManager class to create and lookup Pools on the client side. This is problematic for several reasons:
1. PoolManager is hard to mock because it consists of static methods
2. Being a static singleton with state, PoolManager locks the client into only having one PoolManager and associated ClientCache.
3. The lifecycle of Pools in the PoolManager is strange, they can be created before or after the ClientCache, but they are destroyed when the ClientCache is destroyed.
The solution is to deprecate the static PoolManager and move the Pool management related code to a PoolService that is tied to a ClientCache.
Anti-Goals
It is not a goal of this proposal to support plugging in different types of connection pooling mechanisms into Geode. This proposal is strictly about fixing the issues with the singleton PoolManager.
Solution
We will add a new interface called PoolService, which can be obtained from the ClientCache. It will be similar to PoolManager but it will have instance methods instead of static methods. We will deprecate the PoolManager class.
For now the methods on the new PoolService will just delegate directly to PoolManager. Any pools created with PoolManager or PoolService will be visible in both. In the future we will be able to remove PoolManager entirely once users are migrated to PoolService.
public interface PoolService { // this will delegate to PoolManager.createFactory PoolFactory createPoolFactory(); //Delegates to PoolManager.find Pool find(String name) { //Delegates to PoolManager.getAll Map<String, Pool> getAll(); //The close methods of PoolManager will not be present in PoolService //The lifecycle of PoolService is tied to the cache } public interface ClientCache { ... PoolService getPoolService(); }
One wrinkle is that it is currently possible to create pools and associate them with regions of a Cache, rather than a ClientCache. Cache is intended to be used for server side, peer to peer Caches, which generally don't also have client pools. For that reason, PoolService will only be available on ClientCache.
Performance Impact
n/a
Backwards Compatibility and Upgrade Path
We will be deprecating, not removing PoolManager, so the client will continue to be backwards compatible.
FAQ
Answers to questions you’ve commonly been asked after requesting comments for this proposal.
Errata
What are minor adjustments that had to be made to the proposal since it was approved?
1 Comment
Anilkumar Gingade
Good idea...How about Gateway functionalities using the Connection pool; they are not using ClientCache. It will be nice to have common connection pooling in the product.