RFC Title

To be Reviewed By: 12/11/2019

Authors: Dan Smith

Status: Draft  Draft | Discussion | Active | Dropped | Superseded

...

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 scoped 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  the methods on the new PoolService will just delegate directly to PoolManager. Any pools created with PoolManager or PoolService will be visible in both. However, in 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(). Javadocs will be copied from that method
  PoolFactory createPoolFactory();   
    
  //Delegates to PoolManager.find
    Pool find(String name) {
   
  //Delegates to PoolManager.getAll
  static 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

Do you anticipate the proposed changes to impact performance in any way? Are there plans to measure and/or mitigate the impact?n/a

Backwards Compatibility and Upgrade Path

We will be deprecating, not removing PoolManager, so it 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?