Upgraded c3p0 from 0.9.5.5 to 0.10.0, getting error java.lang.NoSuchMethodError: java.sql.Connection.beginRequest()
KhushbooYadav21 opened this issue · comments
Hi @swaldman,
We are trying to upgrade c3p0 version from 0.9.5.5 to 0.10.0 due to an exception(ConcurrentModificationException) coming in 0.9.5.5. However when we did jar changes for c3p0-0.10.0 and mchange 0.3.0, we are getting below error while server startup and server is not coming up. (We are using Java 8 and Ojdbc 1.8 jar along with Hibernate 4.3.8.Final)
Error stacktrace:
29-Apr-2024 15:13:53.967 SEVERE [http-nio-172.27.77.47-7803-exec-3] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service(
) for servlet [CelliciumHelper] in context with path [/CoreTxn] threw exception [Servlet execution threw an exception] with root cause
java.lang.NoSuchMethodError: java.sql.Connection.beginRequest()V
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$LiveRequestBoundaryMarker.attemptNotifyBeginRequest(C3P0PooledConnec
tionPool.java:145)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.markBeginRequest(C3P0PooledConnectionPool.java:217)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:726)
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:105)
at org.hibernate.c3p0.internal.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:90)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProviderJdbcConnectionAccess.obtainConnection(JdbcServic
esImpl.java:279)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:124)
at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:111
)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:234)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:206)
at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1887)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1845)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1930)
at com.mmoney.dbutilities.HibernateUtil.rebuildSessionFactory(HibernateUtil.java:145)
at com.mmoney.dbutilities.HibernateUtil.getSession(HibernateUtil.java:60)
at com.mmoney.dbutilities.Database.getSelectResult(Database.java:139)
at com.mmoney.dbutilities.Database.getSelectResult(Database.java:43)
at com.mmoney.dao.SysLocaleMasterDAO.findAllLanguageCode(SysLocaleMasterDAO.java:176)
at com.mmoney.dao.SysMessageDAO.loadAllSysMessages(SysMessageDAO.java:75)
at com.mmoney.action.CelliciumHelper.makeList(CelliciumHelper.java:94)
at com.mmoney.action.CelliciumHelper.doPost(CelliciumHelper.java:75)
Kindly look into it and please advise for solution
Hi!
Can you let me know whether there's some reason the pool might obtain Connections from multiple JDBC drivers?
JDBC 4.3 added begin/endRequest methods to Connection, but of course older drivers don't support that. For each pool, c3p0 0.10.0 tries to check for the existence of those methods, to decide whether to call them or not. It does this just once, the first time it acquires Connections, but c3p0 assumes all Connections acquired by a pool will be homogeneous.
Looking at OJDBC, version 8 supports only JDBC 4.2, so would not have these methods. https://www.oracle.com/database/technologies/maven-central-guide.html
What's peculiar is that should be fine, we should simply revert to not calling them.
I presumed that if for some reason those methods were detected and then later were somehow not present (a condition that should really never occur!), the error that would result would be an AbstractMethodError, and I handled that, rather than the NoSuchMethodError you are seeing. So one thing I can do is add a handler for NoSuchMethodError.
I really didn't give a lot of thought to this handler, because I thought this is a condition that should never occur, but I think if it does occur, when it does occur I should log something pretty nasty about it, then turn off all attempts to use begin/endRequest() (which are fundamentally optional hints to the JDBC driver, championed, ironically perhaps, by Oracle).
If you're interested, the relevant code is here: https://github.com/swaldman/c3p0/blob/0.10.x/src/com/mchange/v2/c3p0/impl/C3P0PooledConnectionPool.java#L123-L218
You can see in findRequestBoundaryMarker(...) we are very conservative about turning this on, we do so only when both begin/endRequest() are detected and can be made accessible.
(The accessibility stuff is a holdover from an earlier, reflective implementation, which after profiling performed poorly. Perhaps that should be replaced with just a test for the modifier public, which is what these methods ought to be.)
Okay! With thanks to you and @skarzhevskyy, I think this issue is resolved, though I don't have an Oracle back-end to test it on.
If you want to try it out, a SNAPSHOT release is available on repository https://www.mchange.com/repository as com.mchange:c3p0:0.10.1-SNAPSHOT
SNAPSHOTs are as they usually are unstable, overwritable, so please don't permanently depend on this. I'll try to get it into a real 0.10.1 release soon, but I'd love feedback about whether it fully addresses the issue before I do.
Thanks!
https://www.mchange.com/repository is not accessible.
@AbhishekSinha266 It is accessible, it's just that directory indexing isn't enabled. If you add that URL as a repository to your build tool, it should work.
If you want to access the relevant files directly:
- https://www.mchange.com/repository/com/mchange/c3p0/0.10.1-SNAPSHOT/c3p0-0.10.1-SNAPSHOT.pom
- https://www.mchange.com/repository/com/mchange/c3p0/0.10.1-SNAPSHOT/c3p0-0.10.1-SNAPSHOT.jar
I hope this helps!
Hi! c3p0-0.10.1 is now a release. This issue should be addressed in that version. I'll close it for now. If anything goes wrong, please feel free to submit a new issue or reopen this one. Thanks!