our project is deployed on the cloud but we need to shutdown and restart tomcat7 everyday otherwise "org.hibernate.exception.JDBCConnectionException: Cannot open connection" exception will rise, please help me to resolve this.
I'm guessing that you have a leak somewhere in your code which gets a connection without returning it to the pool (via Connection.close()).
Spring's JdbcTemplate exists mainly to prevent cases like this from ever occurring.
I'd look through the code for methods which get a connection but don't call Connection.close() in a finally block.
I recently wanted to prevent connection leaks but didn't want all of spring's dependencies so I wrote a very simple JdbcTemplate here. You might consider doing the same to avoid this from happening again (or use spring's version)
Related
If I use JDBCTemplate, is the connection automatically closed even if i dont use try with resources (or incase I am throwing an exception in a catch block assuming some sqlexception occured) ? Is JDBCTemplate smart enough?
https://www.javatpoint.com/spring-JdbcTemplate-tutorial
This resource says:
It takes care of creation and release of resources such as creating and closing of connection object etc. So it will not lead to any problem if you forget to close the connection.
So by usnig JDBCTemplate, one can simply forget about connection closing?
Yes, you can forget about connection closing.
When you have questions about something mentioned in a tutorial, you should always check the documentation. You should definitely do that before asking here.
If you had checked the documentation, you'd have found:
3.3.1. Using JdbcTemplate
JdbcTemplate is the central class in the JDBC core package. It handles the creation and release of resources, which helps you avoid common errors, such as forgetting to close the connection. It performs the basic tasks of the core JDBC workflow (such as statement creation and execution), leaving application code to provide SQL and extract results.
It goes on, of course, so you should really click the link and read it for yourself.
The documentation is well-written, so there is no good excuse not to read it and/or reference it when in doubt.
I've a Spring Boot Java application in production that uses ActiveJDBC to access a MariaDB database.
If at launch the application boots before the db server, of if the db server crashes and restarts, the apps doesn't re-estabilish the connection with the db.
ActiveJDBC is on version 1.4.13 and if possible I'd prefer not upgrading it, to avoid possible breakages. The db parameters are configured using the database.properties file and typically the usage pattern is:
try {
Base.open();
...
} finally {
Base.close();
}
Is there a way to circumvent this problem, without monitoring and relaunching the application? Maybe using connection pools? If this is the case, are there any docs or examples?
If you are using a direct JDBC connection in your database.properties file, a new connection will be open every time you execute Base.open(). This means that any old connection that is broken is not relevant anymore. If you use a JDNI pool such as:
production.jndi=java:comp/env/jdbc/acme
then you want to configure your containers' pool to ensure that every connection served from the pool is valid just before the pool serves the connection to your app. It is up to the implementation and documentation of your container/pool how to do that.
In any case, I do not think you are going to have issues.
I am using Hibernate with c3p0 for connection pooling. Since I am working in a multisharded database environment and the possibility of shards' downtime is a realistic use case scenario (by means external to the application at hand, e.g. someone just taking the shard down for whatever reason), I am trying to have c3p0 explicitly close the Hibernate session once it detects that the database connection is down so that I can skip the particular shard's session in my multi-shard scan.
Is there a way to configure c3p0 to notify Hibernate, by invoking Session.close() once it finds out that the connection is down so that calling Session.isOpen() can return a meaningful boolean?
RELATED: Preemptively and gracefully check that org.hibernate.Session is still connected (via c3p0)
the short answer is no, c3p0 won't help you here.
it sounds like (looking here and at your previous question) you are doing something that works at cross-purposes to c3p0, that is you are holding long-lived Sessions rather than creating Sessions on an as-needed basis and then destroying them promptly. that kind of thing is very fragile. it is the architecture Connection pools exist to avoid.
your best choice, IMO, would be "don't do that". don't ever cache Sessions at all. then ordinary Connection testing (perhaps with checkoutTimeout set too) will resolve the problem. if a shard is down, attempts to acquire a Connection will fail, and you can skip the shard if that's the best workaround.
c3p0 knows nothing whatsoever about hibernate. c3p0's author is grateful to hibernate for popularizing his (my) library, but c3p0 has no idea what a Session is, just a Connection. the only way that c3p0 could help you a little bit, in theory, would be that it could report to you an event when it notices that a database is down (which might be quite promptly or quite slowly depending on your configuration). you could respond to the event by close()ing sessions.
unfortunately, c3p0 doesn't (yet) offer hooks through which users could respond to acquisition failures. it might — that's a feature i'm thinking about adding for 0.9.6. but it doesn't now. however, it would be pretty trivial to implement something that polls your shards and closes their Sessions yourself. all c3p0 would do to notice outages would be to call DriverManager.getConnection( ... ) or dataSource.getConnection()and observe Exceptions. you can do that yourself!
i still strongly recommend the first solution, though. get rid of the long-lived Session objects.
My application is trowing the following exception:
java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6#4fe91321
This is happening in production I'm not able to get this problem in development and for that I'm not able to solve it.
The root of the exception is code line dbConn.prepareStatement(sql);
From what I was able to find in the web, the cause for this can be:
Over jdbc connection, a jboss connection is wrapped but the wrapper is empty. The original jdbc connection inside is no longer there.
JDBC Connection is already closed and trying to work with close connection is the reason why I'm getting this exception.
The transaction manger detects transaction that is taking to long then the transaction timeout.
So if someone can point me what is the problem because I'm not able to get this problem in mine development environment.
Also what logs can I add that will help me detect the problem in production - I'm using Java, JBoss, Postgre.
I'have enable connection close monitoringa, and also to add is that the issue is not consistent
I just resolved the issue.
It's my jndi driver not compatible with the latest java frameworks.
I'm using Oracle db and ojdbc6, and i download a latest ojdbc6 from maven repository and replace the old same name jar file. It works like bird now.
If you are using an EJB, it's possible that your Stateless Session Bean Pool is not big enough. The connection can't find an associated thread.
Maybe you have an extended Transaction for a not Stateful Session Bean, wich is maybe not a good idea.
I'm using a singleton class for a PostgresSQL connection inside a servelet. The problem is that once it is open it works for a while (I guess until some timeout), and then it starts throwing a I/O exception. Any idea what is happening to the singleton class inside Tomcat VM?
Thanks
I have no idea. Just do the right thing and do not reinvent the wheel.
Use a DataSource. Either obtain it via JNDI, or do it yourself (I like using Spring, but if your web application is very simple, it's probably overkill).
Use a DataSource.
There's no singleton inside Tomcat; that's just the way connections work when you only have one and keep it open for a long time. It's called "timeout".
This design cannot scale. A better solution is to keep connections open for as short a time as possible. Your code should open a connection, use it, and close it in transaction scope.
You should also set up a connection pool in Tomcat.
and then it starts throwing a I/O exception
Well, what is the exception exactly?
Also, as a note, it's safe to use the same Postgres JDBC connection from multiple threads, but it is not recommended to do so.