It looks like we never came to a consensus on this thread, and meanwhile the urgency for this fix has gone away. The original urgency was to give spring data geode a way to avoid using internal APIs, but that has been fixed a different way in SDG.
I still think this would be a good change to make to get away from needing singletons in the future, but for now I've moved this to the icebox. -Dan On Mon, Dec 9, 2019 at 5:20 PM Dan Smith <dsm...@pivotal.io> wrote: > 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 >
