|
History
| Log In
|
|
|
|
from c3p0:
It is backwards compatable, 100%. You should be able to just drop it in (as I did, using the bundled version of c3p0). Users should see no change in behavior, even with quite old versions of c3p0. Try it with 0.9.0. (There have been other ways to configure c3p0 besides PoolConfig for a long time -- I checked back to c3p0-0.8.5 and the requisite API is there. I think it goes back even further.) The only very minor change users might see is that for parameters that users don't explicitly set in hibernate's config, the default values will be c3p0's defaults rather than those the old ConnectionProvider set. The old C3P0ConnectionProvider had hardcoded defaults: minPoolSize -> 1 maxPoolSize -> 100 acquireIncrement -> 1 while c3p0's defaults for these parameters are: minPoolSize -> 3 maxPoolSize -> 15 acquireIncrement -> 3 Hibernate's other defaults are identical to c3p0's. The only change users will see is if they don't set the minimum or maximum size of the pool, or the acquire increment, the default value will be different. In practice, I think this will be quite harmless, as users usually do specify these parameters. Other than that, users should be able to use their existing configuration and libraries without problems. I don't know if this is related, but there is a problem with SchemaUpdate in Hibernate 3.2.1 that didn't exist in 3.2.0cr3. They have the same version of c3p0, but maybe the usage has changed to make the bug appear.
What happens is that the SchemaUpdate opens two new connections for each table but doesn't seem to close them. I have tested with MySQL and Postgres which both have a 'max connections' setting of 100. So, when the SchemaUpdate gets to table 49 or 50 it writes out error messages: 14:43:58,253 WARN BasicResourcePool:1222 - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@edf4c8 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). There are three workarounds to the problem: 1. Revert back to Hibernate 3.2.0.cr3 (not really an option) 2. Increase the 'max connections' setting for the database 3. Disable c3p0 by removing it from hibernate.cfg.xml None, I can post a debug.level output if somebody want's it. In any case here is the last few lines of it before the failure: 14:45:40,640 INFO ConnectionProviderFactory:72 - Initializing connection provider: org.hibernate.connection.C3P0ConnectionProvider 14:45:40,640 INFO C3P0ConnectionProvider:50 - C3P0 using driver: org.postgresql.Driver at URL: jdbc:postgresql:base2 14:45:40,640 INFO C3P0ConnectionProvider:51 - Connection properties: {user=base2user, password=****, release_mode=after_transaction} 14:45:40,641 INFO C3P0ConnectionProvider:54 - autocommit mode: false 14:45:40,723 INFO SettingsFactory:81 - RDBMS: PostgreSQL, version: 8.0.4 14:45:40,723 INFO SettingsFactory:82 - JDBC driver: PostgreSQL Native Driver, version: PostgreSQL 8.1 JDBC3 with SSL (build 407) 14:45:40,724 INFO Dialect:151 - Using dialect: org.hibernate.dialect.PostgreSQLDialect 14:45:40,725 INFO TransactionFactoryFactory:31 - Using default transaction strategy (direct JDBC transactions) 14:45:40,725 INFO TransactionManagerLookupFactory:33 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended) 14:45:40,726 INFO SettingsFactory:134 - Automatic flush during beforeCompletion(): disabled 14:45:40,726 INFO SettingsFactory:138 - Automatic session close at end of transaction: disabled 14:45:40,726 INFO SettingsFactory:153 - Scrollable result sets: enabled 14:45:40,726 DEBUG SettingsFactory:157 - Wrap result sets: disabled 14:45:40,727 INFO SettingsFactory:161 - JDBC3 getGeneratedKeys(): disabled 14:45:40,727 INFO SettingsFactory:169 - Connection release mode: after_transaction 14:45:40,727 INFO SettingsFactory:196 - Default batch fetch size: 1 14:45:40,727 INFO SettingsFactory:200 - Generate SQL with comments: disabled 14:45:40,728 INFO SettingsFactory:204 - Order SQL updates by primary key: disabled 14:45:40,728 INFO SettingsFactory:369 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory 14:45:40,728 INFO ASTQueryTranslatorFactory:24 - Using ASTQueryTranslatorFactory 14:45:40,728 INFO SettingsFactory:212 - Query language substitutions: {} 14:45:40,729 INFO SettingsFactory:217 - JPA-QL strict compliance: disabled 14:45:40,729 INFO SettingsFactory:222 - Second-level cache: enabled 14:45:40,729 INFO SettingsFactory:226 - Query cache: enabled 14:45:40,729 INFO SettingsFactory:356 - Cache provider: org.hibernate.cache.EhCacheProvider 14:45:40,731 INFO SettingsFactory:241 - Optimize cache for minimal puts: disabled 14:45:40,731 INFO SettingsFactory:250 - Structured second-level cache entries: disabled 14:45:40,731 INFO SettingsFactory:343 - Query cache factory: org.hibernate.cache.StandardQueryCacheFactory 14:45:40,731 DEBUG SQLExceptionConverterFactory:52 - Using dialect defined converter 14:45:40,732 INFO SettingsFactory:277 - Statistics: disabled 14:45:40,732 INFO SettingsFactory:281 - Deleted entity synthetic identifier rollback: disabled 14:45:40,732 INFO SettingsFactory:296 - Default entity-mode: pojo 14:45:40,770 INFO TableMetadata:39 - table found: public.Groups 14:45:40,770 INFO TableMetadata:40 - columns: [removed, system_id, description, name, id, quota_id, version] 14:45:40,770 INFO TableMetadata:42 - foreign keys: [fk7fa2c5f49d6885da] 14:45:40,771 INFO TableMetadata:43 - indexes: [groups_pkey] 14:45:40,771 INFO ConnectionProviderFactory:72 - Initializing connection provider: org.hibernate.connection.C3P0ConnectionProvider 14:45:40,771 INFO C3P0ConnectionProvider:50 - C3P0 using driver: org.postgresql.Driver at URL: jdbc:postgresql:base2 14:45:40,772 INFO C3P0ConnectionProvider:51 - Connection properties: {user=base2user, password=****, release_mode=after_transaction} 14:45:40,772 INFO C3P0ConnectionProvider:54 - autocommit mode: false ..............................14:46:10,545 WARN BasicResourcePool:1222 - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@1d0e2c9 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). 14:46:10,779 WARN BasicResourcePool:1222 - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@1d0e17a -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). 14:46:10,779 WARN BasicResourcePool:1222 - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@d8fd1a -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). .14:46:10,839 WARN SettingsFactory:109 - Could not obtain connection metadata java.sql.SQLException: Connections could not be acquired from the underlying database! at com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:104) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:236) at com.mchange.v2.c3p0.PoolBackedDataSource.getConnection(PoolBackedDataSource.java:94) at org.hibernate.connection.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:35) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:76) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2002) at org.hibernate.cfg.Configuration.generateSchemaUpdateScript(Configuration.java:947) at org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:140) at net.sf.basedb.core.HibernateUtil.createStaticTables(HibernateUtil.java:444) at net.sf.basedb.core.Install.createTables(Install.java:127) at net.sf.basedb.install.InitDB.main(InitDB.java:64) Caused by: com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source. at com.mchange.v2.resourcepool.BasicResourcePool.awaitAcquire(BasicResourcePool.java:970) at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:208) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:232) ... 9 more it's semi related. in 3.2.1 we unfortunately introduced a bug which result in buildSettings being called for every table when doing schemaudpate/validate. This will of course expose any connection leaking in underlying connectionprovides if you have enough tables.
The bug is fixed in svn. Working on getting 3.2.2 ready. Saw that C3P0 has released 0.9.1, so I am ready to use that as the bundled version. However, just saw the attachement here; what is the purpose of the attachment?
to make c3p0 configuration less weird. Hibernate uses some of its own names and prohibits usage of c3p0's setup; but that is not essential for doing the update to fix the leak bug AFAIK.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Minor
update c3p0 to 0.9.1
my initial comments:
dependent on 0.9.1.x so not backwards compatible
works with c3p0.* options should probably be limited to hibernate.c3p0.* to be stringent.
i would like to add support for c3p0's new named config possibility
...but it all comes down to when 0.9.1.x is deemed better than 0.9.0.x for distribution.