On Fri, Dec 6, 2019 at 10:45 AM Dale Emery <dem...@pivotal.io> wrote:
> > > Dale - are you suggesting a ConnectionPoolService that returns > ConnectionPool instances? > > Yes. > > > Would that mean ConnectionPool would extend Pool and we would deprecate > Pool itself? > > Maybe extend. I worry about extending, for two reasons. > > First, extending would make the new interface depend on the deprecated > one. That feels awkward for reasons I can’t articulate > > Second, extending would mean that the new interface gets all the methods > of the deprecated one whether we want them or not. I don’t know enough > about Pool to have an opinion about whether we want to carry all of its > method signatures forward. > > An alternative to consider: Each ConnectionPool implementation delegates > to a Pool. I suspect that this would make it harder to migrate existing > uses from Pool to ConnectionPool. > We could flip what extends what - Have Pool extend ConnectionPool. Deprecate Pool. This would affect the following public APIs: Pool: Would need to extend a new parent interface called ConnectionPool PoolFactory: Would also need a new parent interface called ConnectionPoolFactory FunctionService: Would need to take ConnectionPool instead of Pool ClientCacheFactory: Deprecate all the setPoolXXX methods and add setConnectionPoolXXX? ClientCache: Deprecate getDefaultPool and add getDefaultConnectionPool? RegionFactory and RegionAttributes: Deprecate setPoolName and add setConnectionPoolName cache-1.0.xsd : Deprecate the <pool> elements and add <connection-pool> elements instead. This will also affect downstream projects that use a pool such as Spring Data Geode - that project will maybe want to rename PoolFactoryBean, etc. I guess I'm not sold that making all these name changes is worth it to users. Just removing the singleton as the current proposal stands is a much smaller scope of change. What do you all think? -Dan
