Is it required/good practice to set the connection reference to null after closing it?
I am closing connections in finally block.
conn.close();
conn = null;
I am facing connection wait timeout exception during performance testing
as the maximum connections are getting exceeded.
You'll see this pattern in use when people want to explicitly throw away a reference, and thus aid garbage collection, and trigger finalisers. This is virtually always redundant.
If the conn variable is used to indicate that a new connection is required (by making it a field, perhaps, and resetting it to null before later reference) then that's a different pattern, but unrelated to immediate resource management.
Related
Say, I'm using connection to database named con (or socket or anything else which is Closable). What happens after close()? Does con become equal to null or there is still something in it? And what is the difference between con.close() and con = null?
When you call close, the object should free all the resources it uses behind the scenes. In case of an instance of java.sql.Connection, it will one of two things:
Free any physical connection to the database, thus freeing resources. This happens when you open a database connection manually e.g. DriverManager.getConnection(...).
Go into a SLEEPING state and wait to be invoked again. This happens when the Connection is handled by a DataSource which is handled by a database connection pool.
Setting the object con = null just assigns null value to a variable, the reference will still be alive until the Garbage Collector decides to remove it. Still, setting the Connection to null doesn't call close method, thus you can have memory leaks.
As a best practice, you should ALWAYS call close method on instances of Closeable or use try-with-resources (available since Java 7) to make sure the resource(s) is(are) always closed.
I am working on some old code and i found that the jdbc connection is being passed on as parameter of a method from one class to another.
When the application is run, jdbc connection leaks are observed. The connection is being closed in the same function from where it is being passed.
Should the connection be closed in every method in which it is being passed as a parameter ?
If it is not required, then can i set the connection to null in every method ? Or please suggest if there is any other way to clear connection leaks.
You must ensure the connection is closed in the same method that opens it. Nothing else will work. The connection should be closed in a finally block to ensure it happens.
Can I set the connection to null in every method?
Only if you like writing pointless code. Setting things to null doesn't close anything, or cure connection leaks, or indeed accomplish anything at all in the case of parameters to a method which is about to exit.
yes definitely you have to close the connection in each method. if your project architecture is mvc. you have some DAO classes in the classes you have the persistence logic. so before closing the connection make sure that the connection is alive or not, make a condition like.
if(connection!=null) {
connection.close();
}
I'm using c3p0. I set up a pooled as follows,
cpds = new ComboPooledDataSource();
cpds.setJdbcUrl(...);
/* connection setup */
spds.setMaxStatements(200);
I have an object that prepares several prepared statements on initialization. In order to do that, I grab a connection (con = getConnection()) from the PooledDataSource and then prepare a statement (e.g., PreparedStatement stmt = con.preparedStatemet(/*sql*/)). The prepared statements are stored as private variables in the object and the current connection is closed at the end of initialization (con.close()). The prepared statements are used in methods of the object.
For prepared statements that update the database, this works just fine. However, when I call a method that uses a prepared statement (stmt.executeQuery()) to query the database, I get the following SQLException
java.sql.SQLException: You can't operate on a closed Statement!!!
at com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:118)
at com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:77)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:127)
Did I get something wrong concerning the usage of c3p0?
Many thanks in advance!
Edit: Obviously, my question is partly based on my lack of understanding. As was pointed out in the definite answer, a PreparedStatement belongs to a connection and whenever the connection is closed, the associated statements should be closed, as well. But if that is the case, I don't understand what the use of c3p0's statement cache is.
you should get the same Exception calling executeUpdate(). JDBC Connection and Statement pooling is designed to be transparent: the same API that works for unpooled DataSources should be used for pooled versions too. There will be a dramatic difference in performance, but the code should be semantically interchangeable.
in an unpooled environment, it should be obvious why your approach fails: a Statement, prepared or otherwise, is a child of a Connection, without which it can't function. you are hoping that in the pooled environment, even though the Connection has been "closed", it should still exist in the pool, so hey, those Statements might be good. but that's a very bad idea (and if your attempts to do updates really are succeeding after the parent Connection has been close()ed, again, that'd be a bug, a bad one.) once a Connection has been "closed" it goes back in the pool, but not forever. other clients will check it out, and start performing transaction work that shouldn't be interrupted by your stale Statements. eventually Connections will be expired out of the pool. what should happened to your retained PreparedStatements then?
c3p0 pools Statements transparently, meaning you should use exactly the same API you would have used with no pooling. Call prepareStatement(...) on your Connection, every time. if you've enabled Statement pooling in c3p0 (as you have), then internally c3p0 will check to see whether the Statement has already been prepared, and if so it will quietly use the cached version rather than forwarding the request to the dbms.
i hope this helps!
Just curious, does a MySql connection with Broken Pipe or EOFException = null?
I'm asking cause it might be causing a logic error in my code. Or is there a way to simulate the broken pipe or eof faster? Currently I'm doing database pooling and I do a check where is the conn !=null, counter++ to keep track of the number of connections in use, but if the above is true, I will do a counter++ when the connection is not valid because it does not actually return a null but an object that is not valid. Hope this makes sense.
Regardless of whether the connection is still valid or not, the no reference to the connection instance will be == to null, unless it is actually null. This is entirely unrelated to whether the connection instance is in a usable state.
A common method to determine the latter is to send a simple query through the connection, after it has been dormant for a while. Depending on your database, it could be as simple as „SELECT 1“
There is not really enough context to answer your question. (Hint: post the actual code!!)
However, in general an unexpected null will result in a NullPointerException, and not some subclass of IOException.
I have lots of method in my database class that all of them have one statement, when should I close the connection? In each method or at the end of database class?
You should close the connection when you are finished your transaction. Since we don't know the contents of the class or its usage, it's impossible to tell when your access of the connection begins or ends.
Actually, that may not even be true if the connection is dedicated for a specific usage and not in a pool. You may want to keep it open for the duration of your application.
We've found that the best policy is to get a connection from the connection pool, execute a single transaction, and then put the connection back into the pool immediately. This way you don't have a connection being held onto for long blocks of logic, thus preventing other threads from using it - which is an issue for scalability.
As a best practice, you should close the connection in the logical place after you are done - right after all of database activity for that task is done.
Generally, you should close a connection in the same method that opens it. Closing and opening connections isn't an arduous task, since modern DB servers keep even closed connections on "hot standby", so they are quickly accessed through a connection pool. Leaving them open though...that can get you in trouble and can be a nightmare to debug.
use lombok and it will handle both try/catch and conn.close() for you
public void doSomething() throws SQLException {
#Cleanup Connection connection = database.getConnection();
}
lombok
It depends when and how repeatedly you are using these methods. If they are sequential you should close the connection only in the end, instead of open and close often
This largely depends on what your Database class does. If your methods are called individually at various times then the methods should be responsible for opening and closing the connection. However, if the class does some kind of big processing operation that calls many methods then you may want to open and close the connection outside of the individual methods.
The most important thing is that wherever you open the connection, you also close the connection. Otherwise you get into the business of making assumptions about the state of the connection which can get you into trouble.
Close the connection (and statement and resultset!) in the same method block as you've acquired it, in the finally block of the try block where they are opened.
The general idiom is:
public void doSomething() throws SQLException {
Connection connection = null;
try {
connection = database.getConnection();
} finally {
if (connection != null) try { connection.close(); } catch (SQLException logOrIgnore) {}
}
}
Closing of connection, statement and resultset should happen in reversed order as they're opened.
If your actual concern is performance, then consider using a connection pool to improve connecting performance, for example C3P0. This by the way does not change the general idiom. Just continue writing the same idiom, the connection pooling implementation will worry itself further under the hoods.
Also see this article for more practices/examples.
Always close the connection when you finish executing your transaction. It is a good practice to obtain and close your connection in the same method. If you have separate transactions that are tightly coupled you might execute them with the same connection, but for best practices, I try to execute one transaction per connection.
If it is an option, don't explicitly mess with connections at all. Use a full blown orm framework like hibernate or use something significantly more lightweight like spring jdbc templates.
It depends somewhat on the context your application operates in. If it's a web app you need to be careful to open your connection, do whatever work is needed, and close the connection quickly. However, in a C/S or batch environment it may be better to acquire the connection and hold onto it as long as the user is interacting "frequently" (for whatever value of "frequently" you choose), especially if the user has expectations of rapid response time and it's expensive (in terms of time or resources) to acquire the connection to your particular variety of database.
I like to set a timer every time the user has the app go to the database. If/when the timer expires, close the connection, then re-open the next time he/she/it wants to hit the database again. Timer expiration can be somewhere between 1 and 20 minutes. Just so long as it's less than the database's "inactivity disconnect" time.
Share and enjoy.