brettwooldridge / hikaricp Goto Github PK
View Code? Open in Web Editor NEW光 HikariCP・A solid, high-performance, JDBC connection pool at last.
License: Apache License 2.0
光 HikariCP・A solid, high-performance, JDBC connection pool at last.
License: Apache License 2.0
I'm occasionally seeing the following error from my app:
! java.lang.IllegalStateException: Value was returned to the bag that was not borrowed
! at com.zaxxer.hikari.util.ConcurrentBag.requite(ConcurrentBag.java:177) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at com.zaxxer.hikari.HikariPool.releaseConnection(HikariPool.java:199) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at com.zaxxer.hikari.proxy.ConnectionProxy.close(ConnectionProxy.java:330) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at com.mchange.v2.sql.filter.FilterConnection.close(FilterConnection.java:327) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.BasicHandle.close(BasicHandle.java:116) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.CloseInternalDoNotUseThisClass$CloseHandler.invoke(CloseInternalDoNotUseThisClass.java:36) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObject.invoke(SqlObject.java:171) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObject$1.intercept(SqlObject.java:75) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.CloseInternalDoNotUseThisClass$$EnhancerByCGLIB$$e389b236.___jdbi_close___(<generated>) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObject.close(SqlObject.java:184) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObjectBuilder.close(SqlObjectBuilder.java:76) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.DBI.close(DBI.java:353) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
What could cause this error to occur? Is this indicative of a connection leak?
Lars Gråmark has reported a scenario where HikariCP does not seem to recover successfully after MySQL connections are killed. This bug is to provide a place to attach materials related to the issue.
What does you think about migration from Javassist to ASM? I can help You to rewrite bytecode generation procedures.
I recently switched my Spring RESTful API data source from DriverManagerDataSource to HikariCp, but my database connections went from 20 connections to 600 connections. Is this suppose to happen?
My settings are as follows:
<bean id="jdbcDataSource"
class="com.zaxxer.hikari.HikariDataSource" destroy-method="shutdown">
<constructor-arg>
<bean class="com.zaxxer.hikari.HikariConfig">
<constructor-arg>
<props>
<prop key="dataSource.url">url</prop>
<prop key="dataSource.user">user</prop>
<prop key="dataSource.password">password</prop>
<prop key="dataSource.cachePrepStmts">true</prop>
<prop key="dataSource.prepStmtCacheSize">250</prop>
<prop key="dataSource.prepStmtCacheSqlLimit">2048</prop>
<prop key="dataSource.useServerPrepStmts">true</prop>
</props>
</constructor-arg>
<property name="dataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" />
</bean>
</constructor-arg>
</bean>
<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
<property name="dataSource" ref="jdbcDataSource" />
</bean>
Stumbled on this interesting tool today. Do you have guidance for expressing the appcontext config instead as a persistence.xml - following your MySQL example using JPA (2.x), Hibernate (4.x)?
I'm trying to configure Hikari, but I'm getting a null pointer right now. HikariPool line 175:
throw new SQLException(String.format("Timeout of %dms encountered waiting for connection.", configuration.getConnectionTimeout()), lastConnectionFailure.getAndSet(null));
lastConnectionFailure
is null. Perhaps a null check is warranted?
Hey @brettwooldridge, finally getting around to playing with HikariCP/Hibernate on a non-profit I support (nlfw.org). Working beautifully so far. Very, very glad to delete C3P0 from the dependencies ;)
For what it's worth, this is my Spring configuration. It might be beneficial to throw something like this in your docs.
https://gist.github.com/brmeyer/bbb8688658dd71752738
Note that I'm using the annotation-based Spring configuration, but the concepts would be similar through XML.
Just thought I'd throw that out there!
I can't seem to be able to get data encoded in UTF-8 (cyrilic , arabic alphabets etc) from my MySQL database. Everything else works correctly and as expected.
Without HikariCP (no connection pooling) I used "useUnicode=true&characterEncoding=UTF-8" as a property for my connection and it worked.
With HikariCP i tried something similar for the configuration:
config.addDataSourceProperty("url", "jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=UTF-8");
I also tried using the following:
config.addDataSourceProperty("characterEncoding",Charsets.UTF_8.name());
config.addDataSourceProperty("useUnicode","true");
Neither worked, the cyrilic characters were shown as ???.
My MySQL version is 5.5.27, but like i said without using connection pooling the character were shown correctly.
Any suggestions/ideas?
I'm getting a strange error when instantiating hikariCP when using java 8.
Here's a description of the problem:
http://www.symphonious.net/2014/03/21/javassist-java-8-invalid-constant-type-15/
The stacktrace is here:
at com.zaxxer.hikari.HikariConfig.(HikariConfig.java:82)
...
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: invalid constant type: 15
at com.zaxxer.hikari.proxy.JavassistProxyFactory.(JavassistProxyFactory.java:63)
... 6 more
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: invalid constant type: 15
at com.zaxxer.hikari.proxy.JavassistProxyFactory.(JavassistProxyFactory.java:103)
at com.zaxxer.hikari.proxy.JavassistProxyFactory.(JavassistProxyFactory.java:57)
... 6 more
Caused by: java.lang.RuntimeException: java.io.IOException: invalid constant type: 15
I have trying to test HikariCP as jndi datasource, but i cannot find the way to add it as jndi datasource in tomcat 7.
If it's possible can you provide the configuration or if not can you add this feature ?
Currently there are two ways of configuring data source properties:
addDataSourceProperty(String propertyName, Object value)
HikariConfig(String propertyFileName)
I'm configuring HikariCP with spring xml configuration and I need to set datasource properties (url, user, password).
I can't call the method addDataSourceProperty from the xml configuration and I would need a real file for the constructor. Could you add possibility to set Properties directly, e.g. method
setDriverProperties(Properties properties)
or constructor
HikariConfig(Properties properties)
The requirements of HikariCP are unclear as the documentation found at the following site do not match those documented on GitHib:
http://brettwooldridge.github.io/HikariCP/
Java 7 is stated as a requirement at the aforementioned link, yet GitHub states Java 6+ is supported.
Following my previous question on SO it would be nice to have automatic rollback for checked-in connections when their autoCommit
is set to false
.
Hey, first of all I'm sorry for creating another Issue but it's definetely not related to new versions, but HikariCP (Or my Implementation of it) in general.
Every X. connection I get from the pool seems to be broken:
[SEVERE] [Netty IO Thread #2] WARN com.zaxxer.hikari.proxy.ConnectionProxy - Connection com.mysql.jdbc.JDBC4Connection@38dfa9cc marked as broken because of SQLSTATE(08003), ErrorCode(0): null
I just get a connection with try (Connection cn = JCProxy.getInstance().getMysqlHandler().getConnection()) {
and it should be closed automatically at the end of the try-catch-block.
The strangest thing about is that every snippet of my code has its own "Interval-of-broken-Connection" as it seems. I got a Plugin for a Minecraft-Proxy-Software. In this plugin there are some Commands. In one command every 2nd connection is broken in another plugin every 3rd connection is broken ... I'm unsure if it's randomly or I am doing something wrong if you want I could send you the full code from one of the commands.
Please add sql operations logging (insert, delete, update, select) like in bonecp
Hi,
Not sure if also related to the previous issue, but on shut-down of the app, I now get get:
[13:22:58.900] [ ] [DEVELOPMENT] [WARN ] [com.zaxxer.hikari.pool.HikariMBeanElf ] [99 ] - Unable to unregister management beans.
javax.management.InstanceNotFoundException: com.zaxxer.hikari:type=Pool (corePool)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) ~[na:1.8.0]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427) ~[na:1.8.0]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415) ~[na:1.8.0]
at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546) ~[na:1.8.0]
at com.zaxxer.hikari.pool.HikariMBeanElf.unregisterMBeans(HikariMBeanElf.java:90) ~[HikariCP-1.3.8.jar:na]
at com.zaxxer.hikari.pool.HikariPool.shutdown(HikariPool.java:239) [HikariCP-1.3.8.jar:na]
at com.zaxxer.hikari.HikariDataSource.shutdown(HikariDataSource.java:225) [HikariCP-1.3.8.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0]
at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0]
at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:349) [spring-beans-4.0.3.RELEASE.jar:4.0.3.RELEASE]
-=david=-
The documentation says the default connectionTimeout
is 30000 ms.
The implementation actually defaults the connectionTimeout
to 5000 ms.
Also, the JavaDoc for connectionTimeout
is actually the JavaDoc for connectionTestQuery
I don't think the main issue is from you but actually that what append:
I run some tests from Maven 3.2.1 that use your lib v1.3.3 on centos 6.5 64b.
I got a Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.zaxxer.hikari.HikariConfig. Classpath look fine with debug mode enable to maven.
It work fine on Windows and even at runtime on centos.
Do you have any clue? The only thing different is the maven lib name that start with an uppercase and everything else with a lowercase.
Maybe did you know how to force a lib to maven.
Thanks
Hi,
I'm using HikariCP within a GlassFish 3.x application server. Datasources are created on demand, kept available for some time and closed after a certain timeout.
HikariPool#shutdown() currently isn't implemented, thus every datasource ever
created (and removed) "leaks" the associated connections as well as one timer
thread.
Probably, shutdown() should
I am running HikariCP 1.2.4 with
HikariConfig config = new HikariConfig();
config.setUseInstrumentation(false);
config.setJdbc4ConnectionTest(true);
config.setAutoCommit(false);
config.setTransactionIsolation("TRANSACTION_REPEATABLE_READ");
Because HikariPool does not reset the autocommit flag (to its default of true) when the connection is returned to the pool, this leads to (comments inline, code from HikariPool, line 152):
Connection connection = (Connection) connectionProxy;
// if connectionProxy is not autocommiting, this will start a transaction
if (!isConnectionAlive(connection, timeout))
{
// Throw away the dead connection, try again
closeConnection(connectionProxy);
timeout -= (System.currentTimeMillis() - start);
continue;
}
if (leakDetectionThreshold > 0)
{
connectionProxy._captureStack(leakDetectionThreshold, houseKeepingTimer);
}
// if autocommit is already false, this is a noop, transaction still running
connection.setAutoCommit(isAutoCommit);
// Exception here, because transaction is already running
connection.setTransactionIsolation(transactionIsolation);
connection.clearWarnings();
I also noticed while debugging that postgres (in my case) will perform a roundtrip to the database on
Connection#setTransactionIsolation and also on Connection#getTransactionIsolation
Maybe the transaction isloation could be cached by HikariCP and only set once on creation of the actual connection?
To see what is going on with the underlying DataSource (PGSimpleDataSource in my case) I use DataSource#setLogWriter. However, I did not find a way to do this with HikariCP.
What I tried:
PrintWriter logWriter = ...;
HikariConfig config = new HikariConfig();
// logWriter is first converted to String, so this does not work
config.addDataSourceProperty("logWriter", logWriter);
// other properties ...
HikariDataSource connectionPool = new HikariDataSource(config);
// Implementation does nothing
connectionPool.setLogWriter(logWriter);
Are there any plans to support this?
Thank you in advance and for your work so far, HikariCP is awesome. :)
I'm using HikariCP together with Spring and it would be nice to specify a default transaction level for handed out connections.
Called like:
HikariConfig config = new HikariConfig();
// Taking transaction name (Connection.TRANSACTION_REPEATABLE_READ)
// so that configuration in properties file is readable
config.setTransactionIsolation("TRANSACTION_REPEATABLE_READ");
If the underlying DataSource would allow it, HikariConfig#addDataSourceProperty could be used, but in the case of postgres, PGSimpleDataSource has no appropriate setter.
Hi,
If my HikariCP config has the wrong database credentials, I'd like my server to fail fast.
Seems like the only way is to wait for acquireRetries * acquireRetryDelay milliseconds, then try to call getConnection(), catch the SQLException and then exit.
Do I have that right?
Thanks,
Mark
Slightly older versions of H2 provide JdbcDataSource#setURL, but not JdbcDataSource#setUrl. That was corrected in a recent revision, however it will cause issues for many Hibernate users. Could PropertyBeanSetter#setTargetFromProperties be improved to handle crappy JDBC impls? ;)
I'm including a workaround in hibernate-hikaricp, for now.
Thanks!
Hi,
Java 1.8u5
HikariCP 1.3.7
Spring 4.0.3.RELEASE
Upgraded from 1.3.6 to 1.3.7 of HikariCP. I now get this exception on startup:
16:12:01.258] [ ] [DEVELOPMENT] [WARN ] [com.zaxxer.hikari.pool.HikariMBeanElf ] [69 ] - Unable to register management beans.
javax.management.NotCompliantMBeanException: MBean class com.zaxxer.hikari.pool.HikariPool does not implement DynamicMBean, and neither follows the Standard MBean conventions (javax.management.NotCompliantMBeanException: Class com.zaxxer.hikari.pool.HikariPool is not a JMX compliant Standard MBean) nor the MXBean conventions (javax.management.NotCompliantMBeanException: com.zaxxer.hikari.pool.HikariPool: Class com.zaxxer.hikari.pool.HikariPool is not a JMX compliant MXBean)
at com.sun.jmx.mbeanserver.Introspector.checkCompliance(Introspector.java:176) ~[na:1.8.0_05]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:317) ~[na:1.8.0_05]
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) ~[na:1.8.0_05]
at com.zaxxer.hikari.pool.HikariMBeanElf.registerMBeans(HikariMBeanElf.java:60) ~[HikariCP-1.3.7.jar:na]
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:128) [HikariCP-1.3.7.jar:na]
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:91) [HikariCP-1.3.7.jar:na]
at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:69) [HikariCP-1.3.7.jar:na]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.8.0_05]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [na:1.8.0_05]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.8.0_05]
at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [na:1.8.0_05]
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) [spring-beans-4.0.3.RELEASE.jar:4.0.3.RELEASE]
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:125) [spring-beans-4.0.3.RELEASE.jar:4.0.3.RELEASE]
i might not have url/user/password - i might just have a DataSource from JNDI
which i'd like wrapped. BoneCP, one of your competitors :) lets me do that.
Right after updating from 1.2.4 to 1.2.6 i've encountered with a strange behaviour.
The DB (MySQL) itself is okay. A bug, i guess?
So here it is (these are the postponed tasks):
[ERROR 14:40:52]: Exception during keep alive check. Connection must be dead.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 746,568 milliseconds ago. The last packet sent successfully to the server was 2 milliseconds ago.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1129)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3720)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3609)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4160)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2819)
at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:5355)
at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.setAutoCommit(ConnectionJavassistProxy.java)
at com.zaxxer.hikari.HikariPool.isConnectionAlive(Unknown Source)
at com.zaxxer.hikari.HikariPool.getConnection(Unknown Source)
at com.zaxxer.hikari.HikariDataSource.getConnection(Unknown Source)
...
...
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3166)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3620)
... 25 more
The database log also contains this, many of them.
Also, i've seen it before, within previous releases of HikariCP.
Don't know if it is a normal behaviour, but i never seen so much "aborted connections" in log when been using BoneCP, for example.
140115 15:10:02 [Warning] Aborted connection 216 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
140115 15:10:32 [Warning] Aborted connection 217 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
140115 15:11:02 [Warning] Aborted connection 218 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
140115 15:11:32 [Warning] Aborted connection 219 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
I have a encountered a NullPointerException using the close method of HikariDataSource (1.3.2) when using it as a spring bean.
Following use case. A declared a HikariCP data source as a spring bean in Java config manner. Here is the code:
@Bean(destroyMethod = "close")
public HikariDataSource dataSource(@Value("${db.name}") String databaseName,
@Value("${db.user}") String user, @Value("${dashboard.db.pass}") String password,
@Value("${db.login.timeout.sec}") int loginTimeoutSec,
@Value("${db.connect.timeout.ms}") final int connectionTimeoutMs,
@Value("${db.max.pool.size}") final int maxPoolSize,
@Value("${db.min.pool.size}") final int minPoolSize,
@Value("${db.test.query}") final String connectionTestQuery,
@Value("${db.acq.inc}") final int acquireIncrement) throws SQLException {
MysqlDataSource mysqlDataSource = new MysqlDataSource();
mysqlDataSource.setDatabaseName(databaseName);
mysqlDataSource.setUser(user);
mysqlDataSource.setEncoding("UTF-8");
mysqlDataSource.setUseUnicode(true);
if (!Strings.isNullOrEmpty(password)) {
mysqlDataSource.setPassword(Aes.decrypt(password));
}
HikariDataSource dataSource = new HikariDataSource();
dataSource.setLoginTimeout(loginTimeoutSec); // sec
dataSource.setPoolName("dashboard-server-pool");
dataSource.setConnectionTimeout(connectionTimeoutMs); // ms
dataSource.setMaximumPoolSize(maxPoolSize);
dataSource.setMinimumPoolSize(minPoolSize);
dataSource.setJdbc4ConnectionTest(false);
dataSource.setConnectionTestQuery(connectionTestQuery);
dataSource.setAcquireIncrement(acquireIncrement);
dataSource.setAcquireRetries(1);
dataSource.setAcquireRetryDelay(1000); // ms
dataSource.setDataSource(mysqlDataSource);
return dataSource;
}
As you can see, I am using "close()" as Spring destroy method when shutting down the app. The "close()" effectively does nothing more then delegating to "shutdown()". When shutting down the app, a NullPointerException was raised for HikariDataSource:167
.
The code there shows that the internal pool
instance was not instantiated at that time.
/**
* Shutdown the DataSource and its associated pool.
*/
public void shutdown()
{
boolean shutdown = isShutdown;
isShutdown = true;
if (!shutdown)
{
pool.shutdown();
pool = null;
}
}
I noticed that this is a rare use case, because it only happened because Spring started up but no connection had been used so far, so no pool was created and when the app shuts down the NullPointer was raised.
I managed to workaround this splitting the declaration up into HikariConfig and HikariDataSource. Here is the code:
@Bean(destroyMethod = "close")
public HikariDataSource dataSource(@Value("${db.name}") String databaseName,
@Value("${db.user}") String user, @Value("${db.pass}") String password,
@Value("${db.login.timeout.sec}") int loginTimeoutSec,
@Value("${db.connect.timeout.ms}") final int connectionTimeoutMs,
@Value("${db.max.pool.size}") final int maxPoolSize,
@Value("${db.min.pool.size}") final int minPoolSize,
@Value("${db.test.query}") final String connectionTestQuery,
@Value("${db.acq.inc}") final int acquireIncrement) throws SQLException {
MysqlDataSource mysqlDataSource = new MysqlDataSource();
mysqlDataSource.setDatabaseName(databaseName);
mysqlDataSource.setUser(user);
mysqlDataSource.setEncoding("UTF-8");
mysqlDataSource.setUseUnicode(true);
if (!Strings.isNullOrEmpty(password)) {
mysqlDataSource.setPassword(Aes.decrypt(password));
}
HikariConfig config = new HikariConfig();
config.setPoolName("dashboard-server-pool");
config.setConnectionTimeout(connectionTimeoutMs); // ms
config.setMaximumPoolSize(maxPoolSize);
config.setMinimumPoolSize(minPoolSize);
config.setJdbc4ConnectionTest(false);
config.setConnectionTestQuery(connectionTestQuery);
config.setAcquireIncrement(acquireIncrement);
config.setAcquireRetries(1);
config.setAcquireRetryDelay(1000); // ms
config.setDataSource(mysqlDataSource);
HikariDataSource dataSource = new HikariDataSource(config);
dataSource.setLoginTimeout(loginTimeoutSec); // sec
return dataSource;
}
The constructor call of HikariDataSource
that takes the HikariConfig
parameter initialises the pool within the constructor, so the NullPointerException was not raised during shutdown.
My question is, am I missing something obvious here or is the different behaviour of the HikariDataSource
constructors the desired behaviour? Is the initialisation of the pool
instance missing from no arg constructor?
Given the following config
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
<Arg></Arg>
<Arg>jdbc/DSTest</Arg>
<Arg>
<New class="com.zaxxer.hikari.HikariDataSource">
<Arg>
<New class="com.zaxxer.hikari.HikariConfig">
<Set name="minimumPoolSize">5</Set>
<Set name="maximumPoolSize">50</Set>
<Set name="dataSourceClassName">org.h2.jdbcx.JdbcDataSource</Set>
<Call name="addDataSourceProperty">
<Arg>url</Arg>
<Arg>${jdbc.url}</Arg>
</Call>
<Call name="addDataSourceProperty">
<Arg>user</Arg>
<Arg>sa</Arg>
</Call>
<Call name="addDataSourceProperty">
<Arg>password</Arg>
<Arg></Arg>
</Call>
</New>
</Arg>
</New>
</Arg>
</New>
Caused by: java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at com.zaxxer.hikari.HikariConfig.addDataSourceProperty(HikariConfig.java:311)
is encountered.
Current HikariCP solution contains of 2 parts
java.sql.Connection
to something like javax.sql.PooledConnection
Some JDBC drivers provide javax.sql.ConnectionPoolDataSource
out-of the box. So bytecode generation isn't requred. I propose to split HikariCP for 2 lose-coupled parts:
javax.sql.DataSource
to exact javax.sql.ConnectionPoolDataSource
adapterjavax.sql.ConnectionPoolDataSource
api.In this case you can use both parts if JDBC driver doesn't support javax.sql.ConnectionPoolDataSource
and only second part otherwise...
http://hastebin.com/hilotulifu.avrasm - I'm getting this on startup. But it's limited to the 1.3.4-Version. With the 1.3.3 Version everything works just fine, but with the new 1.3.4 Version I can't start the connection pool.
I would really appreciate some help, thanks!
I am using Spring 4 with Hibernate 4.3 as a JPA provider.
Hibernate does not release connection back to pool when execute INSERT or UPDATE statement.
I tested with c3p0 and tomcat-jdbc have not this problem.
Here is my config:
<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource">
<constructor-arg>
<bean class="com.zaxxer.hikari.HikariConfig">
<constructor-arg>
<props>
<prop key="dataSource.url">${datasource.jdbcUrl}</prop>
<prop key="dataSource.user">${datasource.user}</prop>
<prop key="dataSource.password">${datasource.password}</prop>
<prop key="dataSource.cachePrepStmts">true</prop>
<prop key="dataSource.prepStmtCacheSize">250</prop>
<prop key="dataSource.prepStmtCacheSqlLimit">2048</prop>
</props>
</constructor-arg>
<property name="dataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" />
<property name="minimumPoolSize" value="5" />
<property name="maximumPoolSize" value="15" />
<property name="acquireIncrement" value="1" />
<property name="maxLifetime" value="1800000" />
</bean>
</constructor-arg>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceUnitName" value="DefaultDS"/>
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.MySQL5Dialect</prop>
<prop key="hibernate.show.sql">false</prop>
<prop key="hibernate.format_sql">false</prop>
<prop key="hibernate.use_sql_comments">false</prop>
</props>
</property>
</bean>
ConnectionProxy.java implements a SQLState check to determine if a connection is in a broken state.
The current implementation supports the SQL 2003 standard and Postgres specific codes.
The Sybase JConnect driver has its own proprietary SQL state codes which are documented in the programmers manual available at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc39001.0700/pdf/prjdbc0700.pdf
The state codes which should be treated as connection errors are:
"JZ0C0" - Connection is already closed
"JZ0C1" - An IOException occurred which closed the connection
Unfortunately the JConnect driver chains JZ0C1 inside a JZ006 exception - as documented by the pdf above. I have also experienced behavior where JZ0C0 has been chained inside a JZ006, although this is not mentioned by the spec. In spite of the description given, JZ0C0 can appear without invoking connection.close() explicitly.
The spec suggests that if a JZ006 occurs without any chained exceptions that the connection is still in a usable state - although I have never seen this particular scenario occur in my (limited) usage of the driver to date.
This suggests that a robust implementation would be to add both JZ0C0 and JZ0C1 to the SQL_ERRORS set and then change the behavior of checkException to check both sqle.sqlState and sqle.getNextException.sqlState (when defined) against the error list. JZ006 should not be treated as a connection error.
It'd be handy to be able to construct the pool outside of the datasource.
There's a little problem lying in ConnectionProxy.close().
Example case:
try(final Connection con = Pool.getInstance().getConnection())
{
// e.g forgot to close.
con.createStatement();
con.createStatement();
}
catch (SQLException e)
{
e.printStackTrace();
}
This one leads to this:
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:635)
at java.util.ArrayList.get(ArrayList.java:411)
at com.zaxxer.hikari.proxy.ConnectionProxy.close(Unknown Source)
The cause of this is simple. The size of openStatements stored as a constant.
Then, when the statement is closed (unregisterStatement) - it'll be removed from the List and therefore we cannot use the size constant again which is used for loop as it is points to invalid index (from now).
p.s Shouldn't there be a option for logging such "unclosed" resources? :)
I keep getting these errors even though there are very few connections open. I changed over to DBCP and no issues.
[ERROR] com.zaxxer.hikari.HikariPool - Maximum connection creation retries exceeded: FATAL: remaining connection slots are reserved for non-replication superuser connections
org.postgresql.util.PSQLException: FATAL: remaining connection slots are reserved for non-replication superuser connections
at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:572) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:177) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:64) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:136) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:29) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:21) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:31) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.Driver.makeConnection(Driver.java:410) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.Driver.connect(Driver.java:280) ~[postgresql-9.3-1100-jdbc41
+-com.zaxxer:HikariCP:1.2.5
[info] | +-org.hibernate:hibernate-core:4.3.0.Final
[info] | | +-antlr:antlr:2.7.7
[info] | | +-dom4j:dom4j:1.6.1
[info] | | | +-xml-apis:xml-apis:1.0.b2
[info] | | |
[info] | | +-org.hibernate.common:hibernate-commons-annotations:4.0.4.Final
[info] | | | +-org.jboss.logging:jboss-logging-annotations:1.2.0.Beta1
[info] | | | +-org.jboss.logging:jboss-logging:3.1.3.GA
[info] | | |
[info] | | +-org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final
[info] | | +-org.javassist:javassist:3.18.1-GA
[info] | | +-org.jboss.logging:jboss-logging-annotations:1.2.0.Beta1
[info] | | +-org.jboss.logging:jboss-logging:3.1.3.GA
[info] | | +-org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.0.0.Final
[info] | | +-org.jboss:jandex:1.1.0.Final
[info] | |
[info] | +-org.javassist:javassist:3.18.1-GA
[info] | +-org.slf4j:slf4j-api:1.7.5
There seems to be slight a possibility to connection leak in the pool between acquiring a connection and adding it to the pool. Connection state reset has similar problem as well.
Steps to fix the issue (HikariPool.addConnection):
Currently CodaHaleMetricsTracker is required at compile/runtime to be present even when metrics are not recorded although pom.xml states scope provided. It would not help even if dependency would be marker as optional (as it should, same goes for hibernate).
I think that it would be better to initialize it from a given classname instead of boolean so that other metrics implementations could be used as well. That would fix this problem at the same time.
I'm using my custom ClassLoader (nothing special, just this)
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(new ClassLoader(contextClassLoader) {
});
Seems like bytecode modifications doesn't take effect :(
IHikariConnectionProxy proxyConnection = ProxyFactory.getProxyConnection(this, connection, transactionIsolation, isAutoCommit, isReadOnly, catalog);
proxyConnection.resetConnectionState();
proxyConnection is null (seems like no code generation affected) !!!
JavassistProxyFactory.initialize();
HikariConfig config = new HikariConfig();
setBeanValues(properties, config);
config.setPassword(null);
config.setUsername(null);
config.setDataSource(dataSource);
return new HikariDataSource(config);
removing custom classloader fixes issue
Log say: "idleTimeout is less than 30000ms, did you specify the wrong time unit? Using default instead."
So I had a connection die and HikariCP threw two huge warning messages into my log. Can I either suppress these or replace them with my own message? I don't really care if a connection sitting idle in the pool died, since a new one will just take its place. The first two lines from the two stack traces are below:
2014-04-30 01:00:11 [WARN] Connection com.amshulman.insight.lib.mysql.MySQLConnection@cf5011b (HikariPool-0) marked as broken because of SQLSTATE(08), ErrorCode(-1).
java.sql.SQLNonTransientConnectionException: Could not ping: unexpected end of stream, read 0bytes from 4
2014-04-30 01:00:11 [WARN] Exception during keep alive check, that means the connection must be dead.
java.sql.SQLNonTransientConnectionException: Could not ping: unexpected end of stream, read 0bytes from 4
Hi,
Tomcat guys written another pool and that code base is much more recent. It should be interesting to include this in the benchmark.
Hi,
I'm the author of BoneCP. I'm delighted at finding your project - some interesting ideas out there! Thank you for taking the time to document your techniques. Do you accept contributions? :-)
Might I suggest adding units to your config methods eg InSeconds etc, before I did this, forums were filled with people getting the units wrong, they disappeared when I made the API more explicit. In other words try to avoid the mistakes I made in my initial versions :-)
Setting the DataSource using e.g. org.postgresql.ds.PGSimpleDataSource
seems to be less portable/ideal when supporting multiple DBs at the same time. E.g. PGSimpleDataSource
does not provide for a JDBC url to be specified. Other pool implementations (e.g. BoneCP) provide more of an abstractions level so that I can set the DB properties across the various implementations e.g.
in HikariMBeanElf.java there is line:
LOGGER.error("No registered MBean for {0}.", configuration.getPoolName());
but slf4j doesn't work that way. it should just be {}.
the message i'm seeing in logs is:
No registered MBean for {0}.
Hey brettwooldridge,
I haven't worked with connectionpools a lot, and I stumbled upon the question what I have to do in the finally-block of queries. So without a connection-pool I closed the PreparedStatement, the ResultSet and the Connection. Which of them do I have to close in the finally-block while using HikariCP as ConnectionPool?
Thanks in Advance!
Scrayos
After updating HikariCP from 1.2.8 to 1.3.0 during shutdown Apache Tomcat 7.0.50 I'm getting these messages in catalina.log:
Mar 02, 2014 5:27:40 PM org.apache.catalina.core.StandardServer await
INFO: A valid shutdown command was received via the shutdown port. Stopping the Server instance.
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-apr-8080"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["ajp-apr-8009"]
Mar 02, 2014 5:27:40 PM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service Catalina
Mar 02, 2014 5:27:40 PM org.apache.catalina.core.ApplicationContext log
INFO: Closing Spring root WebApplicationContext
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-apr-8080"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["ajp-apr-8009"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-apr-8080"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["ajp-apr-8009"]
Hi,
Just bumped up to the latest version (from 1.2.1) and now I'm getting this error, which is causing the transaction to rollback. This was okay on 1.2.1 (no code changes, just a version bump).
-=david=-
java.lang.NullPointerException: null
at com.zaxxer.hikari.proxy.ConnectionProxy._checkClosed(Unknown Source) ~[HikariCP-1.2.3.jar:na]
at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.getAutoCommit(ConnectionJavassistProxy.java) ~[na:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_45]
at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_45]
at org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy$LazyConnectionInvocationHandler.invoke(LazyConnectionDataSourceProxy.java:376) ~[spring-jdbc-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at com.sun.proxy.$Proxy21.getAutoCommit(Unknown Source) ~[na:na]
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:68) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) ~[hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
at org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:67) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:110) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
Wrapped by: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is java.lang.NullPointerException
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:430) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:420) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:257) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.data.jpa.repository.support.LockModeRepositoryPostProcessor$LockModePopulatingMethodIntercceptor.invoke(LockModeRepositoryPostProcessor.java:92) ~[spring-data-jpa-1.5.0.M1.jar:na]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at com.sun.proxy.$Proxy109.save(Unknown Source) ~[na:na]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.