C3P0 配置属性

参考资料:https://www.mchange.com/projects/c3p0/#configuration_properties,由于笔者英文水平有限,下面均采用的机器翻译,有问题还请谅解。

配置说明

acquireIncrement

默认值:3

决定当池子用尽时,c3p0一次会尝试获取多少个连接。

acquireRetryAttempts

默认值:30

定义 c3p0 在放弃之前将尝试从数据库获取一个新的 Connection 的次数。如果这个值小于或等于零,c3p0将无限期地尝试获取一个连接。

acquireRetryDelay

默认值:1000

毫秒,c3p0在两次获取尝试之间的等待时间。

autoCommitOnClose

默认值:false

JDBC规范对连接关闭时未解决的、待处理的事务应该如何处理保持沉默,这是不可原谅的。C3P0的默认策略是回滚任何未提交的、待处理的工作。(我认为这绝对是一个正确的策略,但在JDBC驱动供应商中还没有达成共识)。将 autoCommitOnClose 设置为 "true" 会导致未提交的待处理工作被提交,而不是在连接关闭时回滚。[注意:由于规范在这个问题上非常不明确,希望避免错误和不一致行为的应用程序作者应该确保所有事务在调用关闭之前明确地提交或回滚。

automaticTestTable

默认值:null

如果提供,c3p0 将创建一个指定名称的空表,并使用针对该表的查询来测试连接。如果提供了 automaticTestTable,c3p0 将生成它自己的测试查询,因此任何 preferredTestQuery 设置将被忽略。在 c3p0 创建表之后,你不应该再对其进行操作;它应该严格用于 c3p0 在测试你的连接时使用。(如果你定义了自己的 ConnectionTester,它必须实现 QueryConnectionTester 接口,这个参数才有用)。

breakAfterAcquireFailure

默认值:false

如果为true,如果在进行acquisitionRetryAttempts获取连接后无法从数据库中获取连接,池化的DataSource将声明自己被破坏并永久关闭。如果是false,获取连接的失败将导致所有等待池获取连接的线程抛出一个异常,但数据源将保持有效,并将在调用getConnection()后再次尝试获取。

checkoutTimeout

默认值:0

调用getConnection()的客户端在连接池用完后等待连接被检入或获取的毫秒数。零意味着无限期地等待。设置任何正值将导致getConnection()调用超时,并在指定的毫秒数后出现SQLException。

connectionCustomizerClassName

默认值:null

ConnectionCustomizer 接口的实现的完全限定类名,用户可以实现该接口,以便在从数据库获取连接或签出连接时设置连接,并可能在签入和连接销毁时进行清理。如果在ConnectionCustomizer 的 onAcquire() 方法中设置了标准连接属性 (可持续性、只读或 transactionIsolation),则这些属性将覆盖 Connection 的默认值。

connectionTesterClassName

默认值:com.mchange.v2.c3p0.impl.DefaultConnectionTester

ConnectionTester 接口实现的完全限定类名,或者 QueryConnectionTester (如果您希望实例能够访问用户配置的 preferredTestQuery)。这可以用来自定义 c3p0 数据源测试连接的方式,但是随着 automaticTestTable 和 preferredTestQuery 配置参数的引入,对大多数用户来说,“rolling your own” 应该是多余的。

contextClassLoaderSource

默认值:caller

必须是 caller、library 或 none 之一。

决定如何确定 c3p0-spawned Threads 的 contextClassLoader(见 java.lang.Thread)。如果是 caller,c3p0-spawned Threads(helper threads,java.util.Timer threads)从引发池初始化的客户 Thread 继承其 contextClassLoader。如果是 library,contextClassLoader 将是加载 c3p0 类的那个类。如果是 none,则不会设置contextClassLoader(该属性将为 null),这实际上意味着将使用系统 ClassLoader。当客户端应用程序将被应用服务器热重新部署时,调用者的默认设置有时是个问题。当 c3p0 的 Threads 持有对来自第一个客户端的 contextClassLoader 的引用时,当该客户端在运行中的虚拟机中未被部署时,可能无法对与之相关的 ClassLoader 进行垃圾回收。将此设置为库可以解决这些问题。

不支持按用户覆盖。

dataSourceName

默认值:如果使用命名的配置,则为配置名称,否则为池的 "身份令牌"

每个 c3p0 池的数据源都有一个 dataSourceName,它有两个用途。它可以帮助用户通过 C3P0Registry 找到数据源,并且它被包含在 JMX mBeans 的名称中,以帮助跟踪和区分多个 c3p0 数据源,即使在应用程序或 JVM 重新启动时也是如此。dataSourceName 默认为池的配置名称,如果使用了命名的配置,否则就是 "身份令牌"(一个与每个 c3p0 数据源相关的不透明的、保证唯一的字符串)。你可以将此属性更新为你认为方便的任何名称。dataSourceName 不保证是唯一的 —— 例如,从同一个命名配置中创建的多个 DataSource 将共享相同的 dataSourceName。但如果你打算使用 dataSourceName,你可能希望确保你的 JVM 中的所有池状 DataSources 都有唯一的名字。

debugUnreturnedConnectionStackTraces

默认值:false

如果为真,并且 unreturnedConnectionTimeout 被设置为正值,那么池子将捕获所有 Connection 检出的堆栈跟踪(通过异常),并且当未检出的 Connections 超时时,堆栈跟踪将被打印出来。这是为了调试有连接泄露的应用程序,也就是偶尔不能返回连接的应用程序,导致池的增长,并最终耗尽(当池达到 maxPoolSize 时,所有的连接都被检出并丢失)。这个参数只能在调试时设置,因为捕捉堆栈跟踪会减慢每个连接检出的速度。

driverClass

默认值:null

c3p0 将预加载这里指定的任何类,以确保适当的 URL 可以被java.sql.DriverManager 解析为一个驱动实例。如果你希望完全跳过DriverManager 的解析,并确保指定的类的实例被用来提供连接,请将driverClass 与 forceUseNamedDriverClass 结合使用。

不支持按用户覆盖。

extensions

默认值:空的 java.util.Map

一个 java.util.Map(原始类型),包含为该数据源定义的任何用户定义的配置扩展的值。

不支持按用户覆盖。

factoryClassLocation

默认值:null

将被 JNDI 绑定并使用该 API 的 Referenceable 接口来存储自己的数据源可以指定一个 URL,从该 URL 中可以加载能够解读它们的类。如果(通常情况下)c3p0 库将在本地对 JNDI 服务可用,将此设置为空。

不支持按用户覆盖。

forceIgnoreUnresolvedTransactions

默认值:false

强烈不建议这样做。将此设置为 "true" 可能会导致微妙而奇怪的 bug。这是一个糟糕的设置,除非绝对必要,否则不要去管它。它是用来解决那些不能正确支持事务的数据库/JDBC 驱动,但却允许 Connections 的 autoCommit 标志转为 false 的情况。如果你正在使用一个 "部分" 支持事务的数据库(这是矛盾的,因为事务的全部意义在于可靠和完整地执行操作,但尽管如此,这种数据库还是存在的)、如果你觉得可以忽略这样一个事实,即 autoCommit=false 的连接可能处于事务中间,并且可能持有锁和其他资源,你可以关闭 c3p0 的默认行为,即通过回滚(默认)或提交来保护自己,以及数据库的可用性和一致性(见上文 c3p0.autoCommitOnClose)未解决的事务。只有当你确定你使用的数据库允许 Connections 的 autoCommit 标志为 false,但没有提供其他有意义的事务支持时,才应该把它设置为 true。否则将其设置为 "真" 就是一个坏主意。

forceSynchronousCheckins

默认值:false

将此设置为 "true" 可以强制连接被同步签入,这在某些情况下可以提高性能。通常情况下,连接是异步签入的,这样客户端可以避免任何测试或自定义签入逻辑的开销。然而,异步签入会导致线程池拥堵,非常繁忙的线程池可能会发现客户端在等待签入完成时被延迟。扩大 numHelperThreads 可以帮助管理线程池拥堵,但内存占用和切换成本对实际的线程池大小有限制。为了减少线程池的负载,你可以将 forceSynchronousCheckins 设置为 true。当 testConnectionOnCheckin 被设置为 false,并且在ConnectionCustomizer 的 onCheckIn(...) 方法中没有执行慢速工作时,同步签入可能会改善整体性能。如果连接被测试或在签入时执行其他缓慢的工作,那么这个设置将导致客户端在 Connection.close() 中体验到该工作的开销,你必须在池性能的改善中权衡。

forceUseNamedDriverClass

默认值:false

设置参数 driverClass 会使该类预加载并在 java.sql.DriverManager 中注册。然而,它本身并不能确保所使用的驱动是 driverClass 的实例,因为 DriverManager 可能(在不寻常的情况下)知道有其他驱动类可以处理指定的 jdbcUrl。将这个参数设置为 "true" 会使 c3p0 忽略 DriverManager,直接实例化 driverClass。

不支持按用户覆盖。

idleConnectionTestPeriod

默认值:0

如果这是一个大于 0 的数字,c3p0 将每隔一定的秒数测试所有空闲的、被池化但未被选中的连接。

initialPoolSize

默认值:3

一个池子在启动时将尝试获取的连接数。应该是在 minPoolSize 和 maxPoolSize 之间。

jdbcUrl

默认值:null

数据库的 JDBC URL,可以并且应该从该数据库获取连接。应该通过 java.sql.DriverManager 解析到一个合适的 JDBC 驱动(你可以通过设置 driverClass 确保其被加载和可用),或者如果你想直接指定使用哪个驱动(并避免 DriverManager 解析),你可以结合 forceUseNamedDriverClass 来指定 driverClass。除非你提供你自己的非池塘数据源,否则必须始终提供一个适合 JDBC 驱动的数据源,无论它如何被解析。

不支持按用户覆盖。

maxAdministrativeTaskTime

默认值:0

在 c3p0 的线程池尝试中断一个明显挂起的任务之前的几秒钟。很少有用。c3p0 的许多函数不是由客户机线程执行的,而是由内部线程池异步执行的。C3p0 的异步直接增强了客户机性能,并通过确保在非锁持有线程中执行缓慢的 JDBC 操作来最小化持有关键锁的时间长度。但是,如果其中一些任务 “挂起”,即它们在很长一段时间内既没有成功也没有失败,则 c3p0 的线程池可能会耗尽,并且管理任务会备份。如果任务只是很慢,那么解决这个问题的最佳方法是通过 numHelperThreads 增加线程的数量。但是,如果任务有时无限期挂起,则可以使用此参数在任务超过设置的时间限制时强制调用任务线程的 interrupt() 方法。无论如何,c3p0 最终都会从挂起的任务中恢复过来,方法是发出 “明显死锁” 的信号 (您将在日志中看到警告),替换线程池任务线程,并 interrupt() 原来的线程。但是,让池进入明显的死锁状态,然后恢复意味着在一段时间内,c3p0 的性能将受到损害。因此,如果您看到这些消息,增加 numHelperThreads 和设置 maxAdministrativeTaskTime 可能会有所帮助。maxAdministrativeTaskTime 应该足够大,以便从数据库获取连接、测试连接或销毁连接的任何合理尝试都可以在设定的时间内成功或失败。零(默认值)意味着任务永远不会中断,这在大多数情况下是最好和最安全的策略。如果任务只是很慢,那么就分配更多的线程。如果任务永远挂起,试着找出原因,同时设置 maxAdministrativeTaskTime 可能会有所帮助。

不支持按用户覆盖。

maxConnectionAge

默认值:0

秒,有效地活了一段时间。比 maxConnectionAge 老的连接将被销毁并从池中清除。这与 maxIdleTime 的不同之处在于它指的是绝对年龄。即使是空闲时间不多的连接,如果超过 maxConnectionAge,也会从池中清除。零表示没有强制执行最大绝对年龄。

maxIdleTime

默认值:0

一个连接在被丢弃之前可以保持池化但未使用的秒数。零意味着空闲的连接永远不会过期。

maxIdleTimeExcessConnections

默认值:0

允许超过 minPoolSize 的连接在池中保持空闲的秒数,然后被剔除。适用于希望积极减少开放的连接数的应用程序,如果在高峰期之后,负载水平降低,不再需要获得的连接,则将池子缩回到 minPoolSize。如果设置了 maxIdleTime,maxIdleTimeExcessConnections 应该更小,如果该参数有任何作用的话。零意味着不执行,多余的连接不会被闲置。

maxPoolSize

默认值:15

一个池子在任何给定时间内将保持的最大连接数。

maxStatements

默认值:0

c3p0 的全局 PreparedStatement 缓存的大小。如果 maxStatements 和 maxStatementsPerConnection 都为零,则不会启用语句缓存。如果 maxStatements 为零,但 maxStatementsPerConnection 为非零值,则会启用语句缓存,但不会强制执行全局限制,只执行每个连接的最大值。maxStatements 控制所有连接缓存的语句总数。如果设置了,它应该是一个相当大的数字,因为每个池化连接都需要它自己的、不同的缓存语句群。作为指导,请考虑在应用程序中经常使用多少个不同的 preparedstatement,并将该数字乘以 maxPoolSize 以得到一个适当的值。尽管 maxStatements 是用于控制语句缓存的 JDBC 标准参数,但用户可能会发现 c3p0 的备选 maxStatementsPerConnection 使用起来更直观。

maxStatementsPerConnection

默认值:0

PreparedStatements 的数量 c3p0 将为单个池连接缓存。如果 maxStatements 和 maxStatementsPerConnection 都为零,则不会启用语句缓存。如果 maxStatementsPerConnection 为零,但 maxStatements 为非零值,则会启用语句缓存,并强制执行全局限制,否则不会对单个 Connection 的缓存语句数量设置限制。如果设置了 maxStatementsPerConnection,则应该将其设置为应用程序中经常使用的不同 preparedstatement 的数量,再加上两个或三个额外的 preparedstatement,这样就不会强制剔除更常见的缓存语句。虽然 maxStatements 是用于控制语句缓存的 JDBC 标准参数,但用户可能会发现 maxStatementsPerConnection 使用起来更直观。

minPoolSize

默认值:3

池在任何给定时间将保持的最小连接数。

numHelperThreads

默认值:3

C3P0 是非常异步的。慢速 JDBC 操作通常由不持有争用锁的帮助程序线程执行。将这些操作分散到多个线程上,允许同时执行多个操作,从而显著提高性能。

不支持按用户覆盖。

overrideDefaultUser

默认值:null

强制用户调用默认 getConnection() 方法时应由 PooledDataSources 使用的用户名。当应用程序池化来自非 c3p0 非池化数据源的连接时,这主要有用。使用 ComboPooledDataSource 或包装任何 c3p0 实现的非池化数据源的应用程序可以使用简单用户属性。

不支持按用户覆盖。

overrideDefaultPassword

默认值:null

强制用户调用默认 getConnection() 方法时应由 PooledDataSources 输入的密码。当应用程序池化来自非 c3p0 非池化数据源的连接时,这主要有用。使用 ComboPooledDataSource 或包装任何 c3p0 实现的非池化数据源的应用程序可以使用简单密码属性。

不支持按用户覆盖。

password

默认值:null

对于使用 ComboPooledDataSource 或任何 c3p0 实现的非池化数据源的应用程序 — DriverManagerDataSource 或 DataSources.unpooledDataSource(... ) 返回的数据源 — 定义将用于数据源的默认 getConnection() 方法的密码。

不支持按用户覆盖。

preferredTestQuery

默认值:null

定义将为所有连接测试执行的查询,如果使用默认的 ConnectionTester(或 QueryConnectionTester 的其他实现,或者更好的 FullQueryConnectionTester)。定义将在数据库中快速执行的首选测试查询可能会显著加快连接测试的速度。(如果未设置 preferredTestQuery,则默认的 ConnectionTester 会对连接的 DatabaseMetaData 执行 getTables() 调用。根据您的数据库,这可能比“普通”数据库查询的执行速度慢。注意:在初始化数据源之前,数据库架构中必须存在运行首选测试查询的表。如果应用程序定义了自己的架构,请尝试改为自动测试表。

privilegeSpawnedThreads

默认值:false

如果为 true,则 c3p0 生成的线程将具有与 c3p0 库类关联的 java.security.AccessControlContext。默认情况下,c3p0 生成的线程(帮助程序线程,java.util.Timer 线程)从引发池初始化的客户端线程继承其 AccessControlContext。这有时可能是一个问题,尤其是在支持热重新部署客户端应用程序的应用程序服务器中。如果 c3p0 的线程持有来自第一个访问它们的客户端的对 AccessControlContext 的引用,则在正在运行的 VM 中取消部署与该客户端关联的类加载器时,可能无法对其进行垃圾回收。此外,客户端线程可能缺少足够的权限来执行 c3p0 所需的操作。将此设置为 true 可以解决这些问题。

不支持按用户覆盖。

propertyCycle

默认值:0

强制实施用户配置约束之前的最长时间(以秒为单位)。确定强制执行 maxConnectionAge、maxIdleTime、maxIdleTimeExcessConnections、unreturnConnectionTimeout 的频率。c3p0 会定期检查连接的年龄,以查看它们是否已超时。此参数确定周期。零表示自动:合适的时间段将由 c3p0 确定。[你可以调用getEffectivePropertyCycle...() 方法,以查找自动选择的时间段。

statementCacheNumDeferredCloseThreads

默认值:0

如果设置为大于 0 的值,则语句高速缓存将跟踪何时使用连接,并且仅在未使用其父连接时才销毁语句。尽管在使用父连接时关闭语句在规范范围内,但某些数据库和/或 JDBC 驱动程序(尤其是 Oracle)不能很好地处理这种情况并冻结,从而导致死锁。将此参数设置为正值应该可以消除此问题。仅当您观察到 c3p0 尝试 close() 缓存语句冻结时,才应设置此参数(通常您会在日志中看到 APPARENT 死锁)。如果设置,此参数几乎应始终设置为 1。基本上,如果您需要多个专门用于销毁缓存语句的线程,则应设置 maxStatements 和/或 maxStatementPerConnection,这样您就不会如此快速地浏览语句。

不支持按用户覆盖。

testConnectionOnCheckin

默认值:false

如果为 true,则将在每次连接签入时异步执行操作,以验证连接是否有效。与 idleConnectionTestPeriod 结合使用,可实现相当可靠、始终异步的连接测试。此外,设置自动测试表或首选测试查询通常会加快所有连接测试的速度。

testConnectionOnCheckout

默认值:false

如果为 true,则在每个连接签出时都会执行一个操作,以验证连接是否有效。如果将其设置为 true,请确保设置有效的首选测试查询或自动测试表。在每个客户端签出时执行(昂贵的)默认连接测试将损害客户端性能。在结帐中测试连接是最简单、最可靠的连接测试形式,但为了获得更好的性能,请考虑使用 idleConnectionTestPeriod 定期验证连接。

unreturnedConnectionTimeout

默认值:0

秒。如果设置,如果应用程序签出但未能在指定时间段内签入 [即 close()] 连接,则池将毫不客气地 destroy() 连接。这允许偶尔发生连接泄漏的应用程序存活下来,而不是最终耗尽连接池。那真是太可惜了。零表示没有超时,应用程序应 close() 自己的连接。显然,如果设置了非零值,则该值应长于应合理签出的任何连接的值。否则,池偶尔会终止活动使用中的连接,这很糟糕。这基本上是一个坏主意,但这是一个常见的功能。修复您的 $%!@% 应用程序,这样它们就不会泄漏连接!暂时将其与 debugUnreturnConnectionStackTraces 结合使用,以找出签出未返回池的连接的位置!

user

默认值:null

对于使用 ComboPooledDataSource 或任何 c3p0 实现的非池化数据源的应用程序(DriverManagerDataSource 或 DataSources.unpooledDataSource() 返回的数据源),定义将用于数据源的默认 getConnection() 方法的用户名。

不支持按用户覆盖。

usesTraditionalReflectiveProxies

默认值:false

已废弃。c3p0 最初使用反射动态代理来实现连接和其他 JDBC 接口。从 c3p0-0.8.5 开始,改用非反射性代码生成的实现。由于这是一个重大更改,并且旧的代码库已被广泛使用和测试,因此添加了此参数以允许用户恢复他们遇到的问题。新的非反身实现速度更快,现在已经被广泛部署和测试,因此此参数不太可能有用。旧的反射代码库和较新的非反射代码库都在维护中,但将来可能会(或可能不会)放弃对旧代码库的支持。

说说我的看法
全部评论(
没有评论
关于
本网站属于个人的非赢利性网站,转载的文章遵循原作者的版权声明,如果原文没有版权声明,请来信告知:hxstrive@outlook.com
公众号