We Keep Coding

Does try-with resource on db connection pool close the connection each time?

I'm using HikariDataSource for managing the connection pool to my Postgres DB.
I'm using try with a resource for getting the connection from HikariDataSource and i want to understand the following:
Is the connection is really close each time?
If yes - There are no pros of working with prepared statements this way?
What is the best practice for using prepared statements with a connection pool?
Here is my connection code:
public <T> CompletableFuture<T> withConnection(FunctionThatThrowsChecedException<Connection, T> action) {
return CompletableFuture.supplyAsync(() -> {
try (Connection connection = ds.getConnection()) {
return action.apply(connection);
} catch (SQLException | IOException e) {
throw new RuntimeException("error while getting collection", e);
}
}, workerThreads);
}
Here some example of executing query with a prepared statement:
public CompletableFuture<Integer> delete(String batchId) {
return postgresProvider.withConnection(connection -> {
PreparedStatement ps = connection.prepareStatement(DELETE_QUERY);
ps.setString(1, batchId);
return ps.executeUpdate();
});
}

No, the connection is returned to the pool when close() is called. The connection pool's Connection wrapper overrides close() that way so the pool can work.
It's not closed.
Just like you normally do. Using a connection pool rarely requires anything special, and if you intend to tune the pool you need to measure performance and actually know what you're trying to do.

why the JDBCs connection of service and dao are the same？

Just a simple demo of MVC.
In the Service class, there is a
JDBCutil db=new JDBCutil();
db.beginTransation();
UserinfoDao dao=new UserinfoDao();
In the UserinfoDao class, there is also a
JDBCutil db=new JDBCutil();
I thought there are two new JDBCutil, but there actually exists only one connection.
Why? Because of the db.beginTransation();? and why?
I am sorry that is my fault that not post the JDBCutil(thanks for the mention of comment), it maybe the "static connection"(looks like Singleton) one connection although two new .the code is
private static Connection conn=null;
private PreparedStatement pst;
//获取Connection连接
public Connection getConnection(){
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
System.out.println("加载Oracle驱动成功");
String url="jdbc:oracle:thin:#10.25.39.252:1521:orcl";
String userName="cccda";
String pwd="123456";
if(conn==null){
conn=DriverManager.getConnection(url, userName, pwd);
}
System.out.println("获取Connection连接成功");
} catch (ClassNotFoundException e) {
System.out.println("加载Oracle驱动失败");
e.printStackTrace();
} catch (SQLException e) {
System.out.println("获取Connection连接失败");
e.printStackTrace();
}
return conn;
}

You are getting a new JDBCutil instance, but that's not an actual JDBC Connection. It might wrap a singleton connection with a per-user instance class. Without the code, we can't tell.
Also, since you see the word new twice, the JDBCutil instances are not the same, but again that doesn't mean they aren't both using the same JDBC Connection.
Odds are the db.beginTransaction() calls code internally that maps back to the same connection. If it didn't I'd imagine that you would have even bigger problems.

How to manage DSLContext in jooq? (close connection)

This is how I implement each jooq query that i want.
UtilClass{
//one per table more or less
static void methodA(){
//my method
Connection con = MySQLConnection.getConexion(); //open
DSLContext create = DSL.using(con, SQLDialect.MYSQL); //open
/* my logic and jooq querys */ //The code !!!!!!!
try {
if ( con != null )
con.close(); //close
} catch (SQLException e) {
} //close
con=null; //close
create=null; //close
}
}
Am I overworking here? / Is it safe to leave the Context and Connection Open?
In case it is safe to leave it open I would rather work with 1 static field DSLContext per UtilClass (and only the commented section would be on my methods). I would be opening a connection for each UtilClass since I am encapsulating the methods per table (more or less).

DSLContext is usually not a resource, so you can leave it "open", i.e. you can let the garbage collector collect it for you.
A JDBC Connection, however, is a resource, and as all resources, you should always close it explicitly. The correct way to close resources in Java 7+ is by using the try-with-resources statement:
static void methodA() {
try (Connection con = MySQLConnection.getConexion()) {
DSLContext ctx = DSL.using(con, SQLDialect.MYSQL); //open
/* my logic and jooq queries */
// "ctx" goes out of scope here, and can be garbage-collected
} // "con" will be closed here by the try-with-resources statement
}
More information about the try-with-resources statement can be seen here. Please also notice that the jOOQ tutorial uses the try-with-resources statement when using standalone JDBC connections.
When is DSLContext a resource?
An exception to the above is when you let your DSLContext instance manage the Connection itself, e.g. by passing a connection URL as follows:
try (DSLContext ctx = DSL.using("jdbc:url:something", "username", "password")) {
}
In this case, you will need to close() the DSLContext as shown above

Java JDBC efficiency: How long should a connection be maintained?

I'm still working on the same problem mention here. It seems to work fine especially after creating an AbstractModel class shown below:
public abstract class AbstractModel {
protected static Connection myConnection = SingletonConnection.instance().establishConnection();
protected static Statement stmt;
protected static ResultSet rs;
protected boolean loginCheck; // if userId and userLoginHistoryId are valid - true, else false
protected boolean userLoggedIn; // if user is already logged in - true, else false
public AbstractModel (int userId, Long userLoginHistoryId){
createConnection(); // establish connection
loginCheck = false;
userLoggedIn = false;
if (userId == 0 && userLoginHistoryId == 0){ // special case for login
loginCheck = true; // 0, 0, false, false
userLoggedIn = false; // set loginCheck to true, userLogged in to false
} else {
userLoggedIn = true;
try{
String query = "select \"user_login_session_check\"(" + userId + ", " + userLoginHistoryId + ");";
System.out.println("query: " + query);
stmt = myConnection.createStatement();
rs = stmt.executeQuery(query);
while (rs.next()){
loginCheck = rs.getBoolean(1);
}
} catch (SQLException e){
System.out.println("SQL Exception: ");
e.printStackTrace();
}
}
}
// close connection
public void closeConnection(){
try{
myConnection.close();
} catch (SQLException e){
System.out.println("SQL Exception: ");
e.printStackTrace();
}
}
// establish connection
public void createConnection(){
myConnection = SingletonConnection.instance().establishConnection();
}
// login session check
public boolean expiredLoginCheck (){
if (loginCheck == false && userLoggedIn == true){
closeConnection();
return false;
} else {
return true;
}
}
}
I've already posted the stored procedures and Singleton Pattern implementation in the link to the earlier question above.
I'm under the impression that I don't need to close the connection to the database after each single data transaction, as it would just slow the application. I'm looking at about 30 users for this system I'm building, so performance and usability is important.
Is it correct to prolong the connection for at least 3-4 data transactions? Eg. Validation checks to user inputs for some form, or, something similar to google's auto-suggest ... These are all separate stored function calls based on user input. Can I use one connection instance, instead of connecting and disconnecting after each data transaction? Which is more efficient?
If my assumptions are correct (more efficient to use one connection instance) then opening and closing of the connection should be handled in the controller, which is why I created the createConnection() and closeConnection() methods.
Thanks.

Your code should never depend on the fact, that your application is currently the only client to the database or that you have only 30 users. So you should handle database connections like files, sockets and all other kinds of scarce resources that you may run ouf of.
Thus you should always clean up after yourself. No matter what you do. Open connection, do your stuff (one or SQL statements) and close connection. Always!
In your code you create your connection and save it into a static variable - this connection will last as long as your AbstractModel class lives, probably forever - this is bad. As with all similar cases put you code inside try/finally to make sure the connection gets always closed.
I have seen application servers running ouf of connections because of web applications not closing connections. Or because they closed at logout and somebody said "we will never have more then that much users at the same time" but it just scaled a little to high.
Now as you have your code running and closing the connections properly add connection pooling, like zaske said. This will remedy the performance problem of opening/closing database connection, which truely is costly. On the logical layer (your application) you doesn't want to know when to open/close physical connection, the db layer (db pool) will handle it for you.
Then you can even go and set up a single connection for your whole session model, which is also supported by DBCP - this is no danger, since you can reconfigure the pool afterwards if you need without touching your client code.

Like Tomasz said, you should never ever depend on the fact that your application will be used by a small number of clients. The fact that the driver will timeout after a certain amount of time does not guarantee you that you will have enough available connections. Picture this: a lot of databases come pre-configured with a maximum number of connections set to (say) 15 and a timeout of (let's say) 10-15 minutes. If you have 30 clients and each does an operation, somewhere around half-way you'll be stuck short on connections.
You should handle connections, files, streams and other resources the following way:
public void doSomething()
{
Connection connection = null;
Statement stmt = null;
ResultSet rs = null;
final String sql = "SELECT ....");
try
{
connection = getConnection();
stmt = connection.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next())
{
// Do something here...
}
}
catch (SQLException e)
{
e.printStackTrace();
}
finally
{
closeResultSet(rs);
closeStatement(stmt);
closeConnection(connection);
}
}
The try/catch/finally guarantees you that the connection will get closed no matter the outcome. If there is some sort of failure, the finally block will still close the connection, just like it would do, if things were okay.
Similarly, with file and streams you need to do the same thing. Initialize the respective object as null outside your try/catch/finally, then follow the approach above.
This misconception makes a lot of Java applications misbehave under Windows, where people don't close files (streams to files, etc) and these files become locked, forcing you to either kill the JVM, or even restart your machine.
You can also use a connection pool such as for example Apache's DBCP, but even then you should take care of closing your resources, despite the fact that internally, the different connection pool implementations do not necessarily close the connections.

You'are right that you don't need to close the connection after each call.
Bare in mind that that modern database implement internal connection pools, but your application still need to connect and retrieve a connection object, and this is what it does now.
You should consider using a database connection pool - there are various Java frameworks to provide you such a solution, and they will define (you will be able to configure of course) when a database connection pool is closed.
In general - you should ask yourself whether your database serves only your application, or does it serve other application as well - if it does not serve other application as well, you might be able to be more "greedy" and keep connections open for a longer time.
I would also recommend that your application will create on start a fixed number of connections (define it in your configuration with a value of "Minimum connections number") and you will let it grow if needed to a maximum connection numbers.
As I previously mentioned - the ideas are suggest are implemented already by all kinds of frameworks, for example - the DBCP project of Apache.

Here is the Singleton Pattern which I initialize the myConenction field in all my Models to:
public class DatabaseConnection {
private static final String uname = "*******";
private static final String pword = "*******";
private static final String url = "*******************************";
Connection connection;
// load jdbc driver
public DatabaseConnection(){
try{
Class.forName("org.postgresql.Driver");
establishConnection();
} catch (ClassNotFoundException ce) {
System.out.println("Could not load jdbc Driver: ");
ce.printStackTrace();
}
}
public Connection establishConnection() {
// TODO Auto-generated method stub
try{
connection = DriverManager.getConnection(url, uname, pword);
} catch (SQLException e){
System.out.println("Could not connect to database: ");
e.printStackTrace();
}
return connection;
}
}
public class SingletonConnection {
private static DatabaseConnection con;
public SingletonConnection(){}
public static DatabaseConnection instance(){
assert con == null;
con = new DatabaseConnection();
return con;
}
}
Of course each and every connection to the database from the app goes through a Model.

Is closing the connection in finalize best practice? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why would you ever implement finalize()?
I saw some java files with the following code:
public void finalize() {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
}
}
}
Is closing a Connection in the finalize method best practice?
Is it enough to close the Connection or does one need to also close other objects such as PreparedStatement?

From Java 7, the best practice for closing a resource is to use a try-with-resource :
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

No, that is not "best practice", or even "passable practice".
You have no guarantee when if at all finalizers are called, so it won't work.
Instead you should scope out resources to a block, like this:
try {
acquire resource
}
finally {
if (resource was acquired)
release it
}

No, the finalizer is unlikely to be called in a timely manner, if ever. Clean up your resources explicitly and certainly.
/* Acquire resource. */
try {
/* Use resource. */
}
finally {
/* Release resource. */
}

Once the Connection object is obtained, use it to execute the PreparedStatement/Statement/CallableStatement which is placed in a try block, then put the house-cleaning jobs like closing the statment, and the conn.
eg:
try{
Connection conn = DriverManager.getConnection(url,username,password);
PreparedStatement pStat = conn.prepareStatement("Drop table info");
pStat.executeUpdate();
}
catch(Exception ex){
}
finally(){
pStat.close();
conn.close();
}