Bug 61303 - Refactoring of ConnectionPool
Summary: Refactoring of ConnectionPool
Status: NEW
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-15 20:45 UTC by João Paulo Lemes
Modified: 2017-07-15 20:45 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description João Paulo Lemes 2017-07-15 20:45:19 UTC
Hello everyone.
I was analyzing the modularization of some classes, and I identified that the class ConnectionPool has an opportunity for cohesion improvement. 
The class Http11Protocol was in the same situation and the problem was solved as follows: The HttpBaseProtocol class was created, and several get() and set() methods that were used only to configure the class parameters were moved from Http11Protocol to HttpBaseProtocol. 
The new class was then accessed through an instance variable in Http11Protocol. This strategy has cleaned and improved Http11Protocol cohesion.
With this in mind, I would recommend creating a new class: ConnectionPoolConfig , and moving the following methods:

getNumTestsPerEvictionRun
setMaxAge
setTestWhileIdle
getPropagateInterruptState
setPassword
getIdle
getDriverClassName
getDataSourceJNDI
setAlternateUsernameAllowed
getValidationInterval
getValidator
setValidationQuery
setUrl
setCommitOnReturn
getPassword
getDbProperties
setTimeBetweenEvictionRunsMillis
setValidationInterval
getName
getUseDisposableConnectionFacade
getUrl
getMinIdle
getRollbackOnReturn
getMaxIdle
getInitSQL
getPoolName
setLogValidationErrors
setJmxEnabled
setRemoveAbandoned
getNotificationInfo
setName
setRollbackOnReturn
getMaxActive
setDataSource
getLogValidationErrors
getJdbcInterceptorsAsArray
setUseDisposableConnectionFacade
getMinEvictableIdleTimeMillis
getRemoveAbandonedTimeout
setDefaultAutoCommit
setDefaultTransactionIsolation
setMinIdle
setValidator
setInitialSize
getConnectionProperties
getInitialSize
setUsername
setDefaultCatalog
getMaxAge
setUseLock
getNumActive
getDefaultAutoCommit
setDataSourceJNDI
setValidationQueryTimeout
getSuspectTimeout
setPropagateInterruptState
setMaxWait
getPoolProperties
getUseLock
getActive
setAbandonWhenPercentageFull
getNumIdle
getMaxWait
getSize
setDriverClassName
setLogAbandoned
setRemoveAbandonedTimeout
setTestOnConnect
getAbandonWhenPercentageFull
setAccessToUnderlyingConnectionAllowed
setTestOnBorrow
setTestOnReturn
setValidatorClassName
setUseEquals
getUsername
setDbProperties
getTimeBetweenEvictionRunsMillis
setIgnoreExceptionOnPreLoad
getDefaultReadOnly
getCommitOnReturn
getPool
setMaxIdle
getDataSource
getWaitCount
getValidationQuery
getValidationQueryTimeout
getDefaultTransactionIsolation
setDefaultReadOnly
getJdbcInterceptors
setFairQueue
getDefaultCatalog
setMaxActive
javax.management.MBeanNotificationInfo[]
setConnectionProperties
setSuspectTimeout
setMinEvictableIdleTimeMillis
getValidatorClassName
setNumTestsPerEvictionRun
setInitSQL
setJdbcInterceptors

from the ConnectionPool.
Those parameters accessed by an instance variable in the ConnectionPool.
Moreover, the orthogonality is the design would be enhanced.

What do you think about that?