How to use mysql custom port in c3p0 datasource? - java

I have a mysql running on 3306 port in my local system. and also there is another mysql is running on 13000. while im trying to connect to 13000 instance still it is connecting to 3306 instance. c3p0 datasource is taking the default port and it is simply ignoring the port. so could some one help on this???
Spring bean:
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="com.mysql.jdbc.Driver" />
<property name="jdbcUrl" value="jdbc:mysql://localhost:13000/dbname?autoReconnect=true" />
<property name="user" value="user" />
<property name="password" value="pwd" />
<property name="idleConnectionTestPeriod" value="55" />
<property name="initialPoolSize" value="10" />
<property name="maxIdleTime" value="60" />
<property name="maxPoolSize" value="15" />
<property name="minPoolSize" value="5" />
</bean>
Edit:
Even simple JDBC program is connecting to 3306.

c3p0 doesn't parse JDBC urls or make any assumptions at all about what's in them. It just asks your JDBC driver (via DriverManager, or via a directly instantiated driver if you configure forceUseNamedDriverClass) to return Connections for the supplied URL. The issue is definitely not that c3p0 is ignoring the nondefault port. c3p0 is ignoring it all. It has no idea and doesn't care.
I'd try to verify that the JDBC URL you think you are configuring is the one that is actually getting through to the pools you are making. If you have multiple MySQL instances on the machine, maybe you have conflicting config somewhere. c3p0 dumps its configuration to your application's logs at INFO level on pool initiation. Look for that, and verify that the URL your c3p0 DataSource is using is the URL you intended to configure.
Otherwise, try to check to see whether a call to DriverManager.getConnection( myJdbcUrl ) gets you to the DBMS you want. That's basically what is calling. (It's actually calling DriverManager.getConnection( myJdbcUrl, info ) where info is a Properties object. Unless you've set forceUseNamedDriverClass to true.)

Finally found the issue. The reason is i am using mysql-connector-java.5.1.9.jar, so there is a bug in that connector. So i changed it to latest version then my issue got resolved.
Thanks.

Related

Autocommit issue with JDK 1.8, Tomcat 9.0.60, ojdbc8.jar and Oracle DB 19c (19.14.0.0.) [duplicate]

I have configured Tomcat JDBC pool in my web application and added maven dependency with version 8.0.38 which is my tomcat version also. Now I get connection from that pool and check value of autoCommit property and it is "true" then I set that connection's autoCommit to "false". Then I commit the transaction, then close that connection. Now I get another connection from pool and check the value of autoCommit property and it was "false". But I was expecting it as true. I also use Apache Common DBCP2 pooling library, and that has not this kind of behaviour. Whenever I get connection from common DBCP2 pool, it return connection with autoCommit set to "true". I have tested and seen this behaviour of tomcat jdbc pool.
Connection con1 = basicDataSourceWrite.getConnection();
con1.setAutoCommit(false);
System.out.println(con1.getAutoCommit()+ " con1 " );
con1.commit();
con1.close();
Connection con2 = basicDataSourceWrite.getConnection();
System.out.println(con2.getAutoCommit()+ " con2 " );
Output of above code is
false con1
false con2
<bean id="basicDataSourceWrite" class="org.apache.tomcat.jdbc.pool.DataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="${mysqlEndpointWrite}" />
<property name="username" value="${mysqlUserWrite}" />
<property name="password" value="${mysqlPasswordWrite}" />
<property name="defaultAutoCommit" value="true" />
<property name="initialSize" value="4" />
<property name="maxActive" value="5" />
</bean>
here setting defaultAutoCommit to "true" even not work for me. it always return connection with autoCoomit false.
So I want to know how common DBCP2 manage this and how to achieve this in tomcat JDBC pool?
This is a known bug (or rather a feature since it hasn't been fixed) of Tomcat JDBC.
Setting the value of defaultAutoCommit isn't enough, you also need to enable interceptors which will actually enforce those settings. This will make the defaultAutoCommit value affect the connections.
<property name="jdbcInterceptors" value="ConnectionState" />

SQLException: I/O Error: Read timed out

I have a Java Spring application connecting to a SQL Server database.
The connection settings are:
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="net.sourceforge.jtds.jdbc.Driver" />
<property name="jdbcUrl"
value="jdbc:jtds:sqlserver://${db.host}:1433/TestDB" />
<property name="user" value="${db.user}" />
<property name="password" value="${db.pass}" />
<!-- these are connection pool properties for C3P0 -->
<property name="minPoolSize" value="10" />
<property name="maxPoolSize" value="100" />
<property name="acquireIncrement" value="5"/>
<property name="maxIdleTime" value="30000" />
</bean>
everything works fine but sometimes I got the following error:
Could not open JDBC Connection for the transaction; nested exception is java.sql.SQLException: I/O Error: Read timed out
I have searched a lot but can't find any clue, any idea or help?
I'm using
<bean id="sqlSession" class="org.mybatis.spring.SqlSessionTemplate">
<constructor-arg index="0" ref="sqlSessionFactory" />
</bean>
in my spring-config xml to get my sqlSession, and in the DAO I use:
#Autowired
SqlSession sqlSession;
and then I execute the queries I want. Is it possible that because the connection is not closed that this error exists?
In my case connections were getting dropped when the nightly db backup job triggered. I'm using jtds/sql-server as well. Here is what I did to fix it:
Create/setup a health-check cron job that executes a simple query from within your application, like a short select from. Call it every 10 minutes or so and log the result. It will give you some feedback about when and why this is happening.
Reduce the idle time parameter (maxIdleTime) in your configuration so that old connections get automatically discarded.
Keep in mind that if you don't change the maxIdleTime and you keep multiple connections open, some of them may remain in a bad state even if you are using the health-check function. Quoting from c3p0 documentation:
By default, pools will never expire Connections. If you wish Connections to be expired over time in order to maintain "freshness", set maxIdleTime and/or maxConnectionAge. maxIdleTime defines how many seconds a Connection should be permitted to go unused before being culled from the pool. maxConnectionAge forces the pool to cull any Connections that were acquired from the database more than the set number of seconds in the past.
Another way to setup a health-check call is by using the idleConnectionTestPeriod parameter. Also check this answer which can give you more ideas on how to set it up.

Clarification regarding EclipseLink JPA properties

I am using EclipseLink JPA version 2.6 and I wanted to use connection pool properties to set minimum and maximum connection in persistence.xml file. But I have two different set of properties as follows
<property name="eclipselink.connection-pool.default.initial" value="1" />
<property name="eclipselink.connection-pool.default.min" value="64" />
<property name="eclipselink.connection-pool.default.max" value="64" />
And
<property name="eclipselink.connection-pool.default.initial" value="1" />
<property name="eclipselink.connection-pool.node2.min" value="16"/>
<property name="eclipselink.connection-pool.node2.max" value="16"/>
I have doubt that which set I have to use in persistence.xml file. Anyone suggest me a best possible way for handling multiple connections.
Check the documentation about partitioning your connection pool. If you not plan to partition your pool, the first settings-block is fine. Check the Connection Pool settings for eclipselink.

Configure two PostgreSQL database(fail over mechanism) using Spring 3

I am using Tomcat JDBC API(org.apache.tomcat.jdbc.pool.DataSource) to connect to my PostgreSQL database from Spring configuration file as shown below. I got a new requirement to configure two databases which should act as a fail over mechanism, Like When one database is down application should automatically switch back to another database.
<bean id="dataSource" class="org.apache.tomcat.jdbc.pool.DataSource"
destroy-method="close">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="jdbc:postgresql://localhost/dbname?user=postgres" />
<property name="username" value="postgres" />
<property name="password" value="postgres" />
<property name="maxActive" value="5" />
<property name="maxIdle" value="5" />
<property name="minIdle" value="2" />
<property name="initialSize" value="2" />
</bean>
Can anyone suggest how this can be achieved using Spring configuration file.
The normal way this is done is by using virtual IP addresses (with possible forwarding), checking for activity, a shoot-the-other-node-in-the-head approach and proper failover. Spring is exactly the wrong solution to this if you want to avoid things like data loss.
A few recommendations.
repmgr from 2ndquadrant will manage a lot of the process for you.
Use identical hardware and OS and streaming replication.
Use virtual IP addresses, and the like. Use a heartbeat mechanism to trigger failover via rempgr
Then from this perspective your spring app doesn't need reconfiguring.

Hibernate and mysql timeout issue

I have been having trouble with Hibernate and Mysql timeout error.I am also using properties of c3p0(connection provider). After my Hibernate/MySQL have been running after 8 hours(which is default timeout value in Mysql), I have the exception. But it doesn't help.
property for auto reconnect also not working.
Here is my Hibernate Configuration:
<property name="connection_provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
**<property name="connection.autoReconnect"> true</property>
<property name="connection.autoReconnectForPools">true</property>**
<property name="connection.is-connection-validation-required">true</property>
<property name="c3p0.validate">true</property>
<property name="current_session_context_class">thread</property>
<property name="cache.use_query_cache">false</property>
<property name="cache.use_second_level_cache">false</property>
<property name="c3p0.idle_test_period">20</property>
<property name="c3p0.timeout">40</property>
<property name="c3p0.max_size">100</property>
<property name="c3p0.min_size">1</property>
<property name="c3p0.acquireRetryAttempts">10</property>
<property name="c3p0.maxPoolSize">100</property>
<property name="c3p0.maxIdleTime">300</property>
<property name="c3p0.maxStatements">50</property>
<property name="c3p0.minPoolSize">10</property>
<property name="c3p0.preferredTestQuery">select 1;</property>
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="connection.url">jdbc:mysql://localhost:3306/doqeap</property>
<property name="connection.user">root</property>
<property name="connection.password">*******</property>
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="hibernate.jdbc.batch_size">0</property>
<mapping></mapping>
please help me to sort out this problem.
Thanks
If the Connection timeout is the issue, then Connection testing should eliminate, wither via tests on checkout (reliable but imposes a client visible performance cost) or tests on checking + idle tests.
Looking at you config params, it looks like you mean to set tests on checkouts and idle tests. I'd expect that c3p0 would eliminate timed out Exceptions before your app saw them. If that hasn't happened, it'd be interesting to see two things: 1) c3p0's config, which gets logged at INFO when the pool is initialized -- is c3p0, through the hibernate layer, seeing the configuration you intend? 2) the Exception that your app receives when it encounters the stale Connections.
Good luck!

Categories