Develop Reference

Is it a good idea to close the JDBC connection in case of PG Listen/Notify polling?

We use connection pool in our application. While I understand that we should close and get connections as needed since we are using a connection pool. I implemented a cache update mechanism by receiving Postgres LISTEN notifications. The code is pretty much similar to the canonical example given by the documentation.
As you can see in the code, the query is initiated in the constructor and the connection is re used. This may pose problem when the connection is closed out of band due to any factor. One solution to this is to get the connection before every use, but as you can see the statement is only executed once in the constructor but still I can receive the notification in the polling. So if I get the connection every time, it will force me to re issue the statement for every iteration(after delay). I'm not sure if that's an expensive operation.
What is the middle ground here?
class Listener extends Thread
{
private Connection conn;
private org.postgresql.PGConnection pgconn;
Listener(Connection conn) throws SQLException
{
this.conn = conn;
this.pgconn = conn.unwrap(org.postgresql.PGConnection.class);
Statement stmt = conn.createStatement();
stmt.execute("LISTEN mymessage");
stmt.close();
}
public void run()
{
try
{
while (true)
{
org.postgresql.PGNotification notifications[] = pgconn.getNotifications();
if (notifications != null)
{
for (int i=0; i < notifications.length; i++){
//use notification
}
}
Thread.sleep(delay);
}
}
catch (SQLException sqle)
{
//handle
}
catch (InterruptedException ie)
{
//handle
}
}
}
In addition to this, there is also another similar document which had another query in run method as well in addition to constructor. I'm wondering if someone could enlighten me the purpose of another query within the method.
public void run() {
while (true) {
try {
//this query is additional to the one in the constructor
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT 1");
rs.close();
stmt.close();
org.postgresql.PGNotification notifications[] = pgconn.getNotifications();
if (notifications != null) {
for (int i=0; i<notifications.length; i++) {
System.out.println("Got notification: " + notifications[i].getName());
}
}
// wait a while before checking again for new
// notifications
Thread.sleep(delay);
} catch (SQLException sqle) {
//handle
} catch (InterruptedException ie) {
//handle
}
}
}
I experimented closing the connection in every iteration(but without getting another one). That's still working. Perhaps that's due to unwrap that was done.
Stack:
Spring Boot, JPA, Hikari, Postgres JDBC Driver (not pgjdbc-ng)

The connection pool is the servant, not the master. Keep the connection for as long as you are using it to LISTEN on, i.e. ideally forever. If the connection ever does close, then you will miss whatever notices were sent while it was closed. So to keep the cache in good shape, you would need to discard the whole thing and start over. Obviously not something you would want to do on a regular basis, or what would be the point of having it in the first place?
The other doc you show is just an ancient version of the first one. The dummy query just before polling is there to poke the underlying socket code to make sure it has absorbed all the messages. This is no longer necessary. I don't know if it ever was necessary, it might have just been some cargo cult that found its way into the docs.
You would probably be better off with the blocking version of this code, by using getNotifications(0) and getting rid of sleep(delay). This will block until a notice becomes available, rather than waking up twice a second and consuming some (small) amount of resources before sleeping again. Also, once a notice does arrive it will be processed almost immediately, instead of waiting for what is left of a half-second timeout to expire (so, on average, about a quarter second).

Database connection from weblogic

Locally everything works fine, but on a remote Weblogic not really. The next code runs without any exception.
try
{
ods = new OracleDataSource();
connectionString = XmlReader.getConnectionString();
ods.setURL(connectionString);
}
catch (SQLException ex)
{
ex.printStackTrace();
}
catch (Exception e) {
e.printStackTrace();
}
When i call getConnection() on the previous ods object, it doesnt raise any exception
try
{
if (connection == null || connection.isClosed()) {
connection = ods.getConnection();
}
}
catch(Exception e) {
e.printStackTrace();
}
But finally the connection object is null
for example after calling this
CallableStatement cstmt = connection.prepareCall( jobquery );
On a database it looks like the application created the connection, but then it doesnt call the procedure specified in "jobquery". What could be wrong?
Simply my question is: Is there a way to create an OracleDataSource without an exception, and then get a null from it?

Nambaris answer will probably solve your immediate issue. Other points to consider:
On weblogic you really should be using built-in datasources and look those up by JNDI name
Are you sure it doesn't throw an exception, or are you just not seeing it due to printing it out on stderr? You should be using logging mechanism and exception propagation, not printing to outputs.
These are not directly related to your problem, just things you should be doing in the long run.

Unless you miss some code in original question, it seems you didn't perform execute().
Example:
callableStatement.executeQuery();
Read this CallableStatement tutorial

JSF page freezes when is reloaded many times

I use this code to fetch data from database table.
public List<Dashboard> getDashboardList() throws SQLException {
if (ds == null) {
throw new SQLException("Can't get data source");
}
//get database connection
Connection con = ds.getConnection();
if (con == null) {
throw new SQLException("Can't get database connection");
}
PreparedStatement ps = con.prepareStatement(
"SELECT * from GLOBALSETTINGS");
//get customer data from database
ResultSet result = ps.executeQuery();
List<Dashboard> list = new ArrayList<Dashboard>();
while (result.next()) {
Dashboard cust = new Dashboard();
cust.setUser(result.getString("SessionTTL"));
cust.setPassword(result.getString("MAXACTIVEUSERS"));
//store all data into a List
list.add(cust);
}
return list;
}
This code is a part of a JSF page which is deployed on glassfish server. The problem is that when I reload the JSF page many times(around 8 times) the web page freezes. I suspect that the thread pool is fill and there is no space for new connections. How I can solve the problem? Close the connection when the query is finished or there is another way?
Best wishes

First of all: Yes you should close your connection when your done by explicitly calling the close() method. Closing a connection will release database resources.
UPDATE: And you should close the PreparedStatement as well (with close()). I would also recommend to handle SQLExceptions in your method and not throw it, since you need to make sure that your statement and connection are closed even if an exception occurs.
Something like this:
Connection connection = dataSource.getConnection();
try {
PreparedStatement statement = connection.prepareStatement();
try {
// Work with the statement
catch (SQLException e ) {
// Handle exceptions
} catch (SQLException e {
// Handle exceptions
} finally {
statement.close();
}
} finally {
connection.close();
}
Furthermore, you should not query the database in a bean field's getter method. Getters can be called several times during each request. The more elegant way would be to prepare the DashboardList in the constructor or #PostConstruct of your bean.

Java JDBC connection status

I am (successfully) connecting to a database using the following:
java.sql.Connection connect = DriverManager.getConnection(
"jdbc:mysql://localhost/some_database?user=some_user&password=some_password");
What should I be checking to see if the connection is still open and up after some time?
I was hoping for something like connect.isConnected(); available for me to use.

Your best chance is to just perform a simple query against one table, e.g.:
select 1 from SOME_TABLE;
Oh, I just saw there is a new method available since 1.6:
java.sql.Connection.isValid(int timeoutSeconds):
Returns true if the connection has not been closed and is still valid.
The driver shall submit a query on the connection or use some other
mechanism that positively verifies the connection is still valid when
this method is called. The query submitted by the driver to validate
the connection shall be executed in the context of the current
transaction.

Nothing. Just execute your query. If the connection has died, either your JDBC driver will reconnect (if it supports it, and you enabled it in your connection string--most don't support it) or else you'll get an exception.
If you check the connection is up, it might fall over before you actually execute your query, so you gain absolutely nothing by checking.
That said, a lot of connection pools validate a connection by doing something like SELECT 1 before handing connections out. But this is nothing more than just executing a query, so you might just as well execute your business query.

Use Connection.isClosed() function.
The JavaDoc states:
Retrieves whether this Connection object has been closed. A
connection is closed if the method close has been called on it or if
certain fatal errors have occurred. This method is guaranteed to
return true only when it is called after the method Connection.close
has been called.

You also can use
public boolean isDbConnected(Connection con) {
try {
return con != null && !con.isClosed();
} catch (SQLException ignored) {}
return false;
}

If you are using MySQL
public static boolean isDbConnected() {
final String CHECK_SQL_QUERY = "SELECT 1";
boolean isConnected = false;
try {
final PreparedStatement statement = db.prepareStatement(CHECK_SQL_QUERY);
isConnected = true;
} catch (SQLException | NullPointerException e) {
// handle SQL error here!
}
return isConnected;
}
I have not tested with other databases. Hope this is helpful.

The low-cost method, regardless of the vendor implementation, would be to select something from the process memory or the server memory, like the DB version or the name of the current database. IsClosed is very poorly implemented.
Example:
java.sql.Connection conn = <connect procedure>;
conn.close();
try {
conn.getMetaData();
} catch (Exception e) {
System.out.println("Connection is closed");
}

Here is a simple solution if you are using JDBC to get the default connection
private Connection getDefaultConnection() throws SQLException, ApiException {
Connection connection = null;
try {
connection = dataSource.getConnection ();
}catch (SQLServerException sqlException) {
// DB_UNAVAILABLE EXCEPTION
}
return connection;
}

Accessing data from servlet

I have got a requirement that mysql database can only be accessed from localhost. I have to implement a servlet that would access the database allowing other servers in this system to access data (servlet would work as a proxy). However, this system consists of a remote server which downloads large portions of data executing a statement like:
select * from database limit 100;
Can somebody suggest me how to write a servlet that would stream such data in a efficient way (I am new to databases)?

First of all, I don't recommend to use a servlet for this. See the answers of aioobe and mdma for the right approach. But if there is really no other option, then continue reading:
Just write the data to the response immediately as the data comes in. Don't store everything in Java's memory. So basically: writer.write(resultSet.getString("col")). Further, the MySQL JDBC driver will by default cache everything in Java's memory before giving anything to ResultSet#next(). You'd like to let it give the data immediately row-by-row by setting the Statement#setFetchSize() as per the MySQL JDBC driver documentation.
Here's a kickoff example, assuming you'd like to output the data in CSV format:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/csv");
Connection connection = null;
Statement statement = null;
ResultSet resultSet = null;
PrintWriter writer = response.getWriter();
try {
connection = database.getConnection();
statement = connection.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
statement.setFetchSize(Integer.MIN_VALUE);
resultSet = statement.executeQuery("SELECT col1, col2, col3 FROM tbl");
while (resultSet.next()) {
writer.append(resultSet.getString("col1")).append(',');
writer.append(resultSet.getString("col2")).append(',');
writer.append(resultSet.getString("col3")).println();
// PS: don't forget to sanitize quotes/commas as per RFC4130.
}
} catch (SQLException e) {
throw new ServletException("Query failed!", e);
} finally {
if (resultSet != null) try { resultSet.close; } catch (SQLException logOrIgnore) {}
if (statement != null) try { statement.close; } catch (SQLException logOrIgnore) {}
if (connection != null) try { connection.close; } catch (SQLException logOrIgnore) {}
}
}

Well, if your goal is to completely open up the sql-server for queries by external hosts, but for some reason don't want to reconfigure it to accept external connections, I would suggest that you simply set up a tunnel for the port which the server listens on.
The remote host would connect to your application (running on localhost), which in turn simply connects to the sql-server and relays the stream of data back and forth.

A JDBC proxy would give you what you are looking for out of the box, such as Virtual JDBC.