dje*_*lin 11 java connection-pooling jdbc c3p0
我想配置我的c3p0连接池,以便至少有2个连接始终处于活动状态,最多5个,并且超过前2个的空闲连接将在合理的时间内(比如一小时)到期.
除了文档似乎暗示有职能部门之间没有区别这一切听起来简单maxIdleTime
且maxIdleTimeExcessConnections
,这是混淆了我.
基本池配置状态:
在minPoolSize和maxPoolSize之间的范围内,池中的连接数根据使用模式而有所不同.每当用户请求连接,没有可用的连接,并且池中尚未达到管理的Connections数量的maxPoolSize时,连接数就会增加.由于连接获取速度非常慢,因此在批量生成中急切地增加连接数量几乎总是有用的,而不是强迫每个客户端等待新连接在负载增加时引发单个获取.acquireIncrement确定当池用完连接时c3p0池将尝试获取的连接数.(无论acquireIncrement如何,池都不会允许超出maxPoolSize.)
和minPoolSize
用法:
池在任何给定时间将保持的最小连接数.
好,太棒了.并且用于配置连接时间:
maxIdleTimeExcessConnections用于在池未加载时最小化c3p0池所持有的Connections数.默认情况下,c3p0池在负载下增长,但只有在Connections通过Connection测试失败或通过上述参数过期时才会收缩.一些用户希望他们的池在强制使用大量池大小的使用高峰后快速释放不必要的连接.您可以通过将maxIdleTimeExcessConnections设置为比maxIdleTime短得多的值来实现此目的,如果它们闲置超过一小段时间,则会强制释放超出设置的最小大小的连接.
所以它暗示minPoolSize
只有在与之结合使用时才有意义maxIdleTimeExcessConnections
,否则,它将完全被忽略.
证实文件maxIdleTime
没有提及minPoolSize
:
秒可以在丢弃之前保持连接但未使用.零意味着空闲连接永不过期.
而且maxIdleTimeExcessConnections
是有道理的:
在剔除之前,应允许超过minPoolSize的连接在池中保持空闲的秒数.适用于希望积极减少打开连接数的应用程序,如果在峰值之后,负载级别减少并且不再需要连接,则将池缩回minPoolSize.如果设置了maxIdleTime,则如果参数有效,则maxIdleTimeExcessConnections应该更小.零意味着没有强制执行,多余的连接不会被闲置.
我觉得很奇怪minPoolSize
,一个基本功能,只有在我看来是一个更高级的功能时使用才有意义.这都是正确的吗?
Ste*_*man 14
多么谨慎和律师的阅读!
但不,这不正确.
Connection有几种方法可以消亡.正如你所说:
c3p0池...如果Connections连接测试失败或通过上述参数过期,则收缩.
在"上述参数"包括maxConnectionAge
,maxIdleTime
,和maxIdleTimeExcessConnections
.连接也可以从池中删除,因为它们在空闲时失败连接测试(请参阅参考资料idleConnectionTestPeriod
),因为它们在签入或签出时失败测试(testConnectionOnCheckin
,testConnectionOnCheckout
),或者因为它们在客户端过程中由异常触发测试失败使用.
然而,池缩小,很minPoolSize
重要,因为如果池缩小到下面minPoolSize
,则销毁的Connections 将被替换直到minPoolSize
恢复.
maxIdleTimeExcessConnections
它的独特之处在于它的行为直接取决于相对于池的大小minPoolSize
.所有其他参数和测试只是做他们的事情.如果他们的事情恰好将游戏池带到低于某个值minPoolSize
,那么c3p0会自动将游戏池带回minPoolSize
.但是maxIdleTimeExcessConnections
不同.当池大于时,它只会产生任何影响minPoolSize
.
如你所说,maxIdleTimeExcessConnections
是一个高级功能.大多数用户永远不会,也不需要使用它.之所以添加它是因为有些用户希望积极地强制池缩小回minPoolSize,但是使用非常短的无条件执行此操作maxIdleTime
会导致不必要地通过Connections流失,因为即使在minPoolSize
池中的Connections也会不断过期并被替换.设置一个很长或不存在maxIdleTime
,而设置一个短路maxIdleTimeExcessConnections
产生快速,积极收缩的预期结果,而不会在游泳池点击时通过Connections搅动minPoolSize
.
但即使没有maxIdleTimeExcessConnections
设定,也minPoolSize
非常重要.连接确实从池中被销毁并被清除,并minPoolSize
确定一个阈值,在该阈值之下,即使没有客户端负载引起池扩展,也会自动替换被破坏的Connections.
我希望这是有道理的!