I created one thread with java.sql.Connection and String parameters.
But from within the thread, I observed that String value was available but Connection object was not. Any clues?
(Editing details into question):
Well, it seems the connection object is available, but closed inside the thread.
Here's the code:
package com.catgen.helper;
import java.sql.Connection;
public class ImageCheckHelper extends Thread{
public Connection conn = null;
public String str = null;
public ImageCheckHelper(Connection conn, String str){
this.conn = conn;
this.str = str;
try{
System.out.println("From inside the constructor");
System.out.println((this.conn!=null)?"Connection is not null":"Connection is null");
System.out.println((this.str!=null)?"String is not null":"String is null");
System.out.println((this.conn.isClosed())?"Connection is closed.":"Connection is not closed");
System.out.println("\n\n");
}catch(Exception e){
e.printStackTrace();
}
}
public void run(){
try{
System.out.println("From inside the thread");
System.out.println((conn!=null)?"Connection is not null":"Connection is null");
System.out.println((str!=null)?"String is not null":"String is null");
System.out.println((conn.isClosed())?"Connection is closed.":"Connection is not closed");
}catch(Exception e){
e.printStackTrace();
}
}
public void initiateImageCheck(){
this.start();
return;
}
}
And here's the output:
From inside the constructor
Connection is not null
String is not null
Connection is not closed
From inside the thread
Connection is not null
String is not null
Connection is closed.
Is another thread closing the connection between the time it is given to the constructor and the time it is used in the run() method? My guess is that the connection is closed after the call to initiateImageCheck() returns but before the run() method has got as far as the isClosed() check.
If not, do you have access to the JDBC driver's source code? I wonder if it is protecting itself against multi-threaded use.
Connections are not guaranteed to be thread-safe, so you should obtain the connection from within the thread that is going to use it.
You also have unsynchronized access to conn from two different threads. Public member variables are not a good idea either - especially in classes that need to be thread-safe.
I don't see what your problem is - looking at the output, you can see that both the Connection and String are non-null within the constructor and when you come to run the thread.
The only difference is that the connection has been closed at some point between the thread being constructed, and the thread being run. Depending on how you provided the connection, and how other threads were using it, this is not particularly unusual. In any case, you should be looking at other threads calling close() on the same Connection object if you want to track this down.
As a general guideline, it's typically easiest to have each thread manage its own Connection, because otherwise you end up with some very tricky semantics about committing and closing them (as you've seen here). Sharing a connection between multiple threads can work, and on rare occasions is necessary, but in general it should be the exception rather than the rule.
Edit: Additionally, a lot of Connection implementations are not even threadsafe, so you can't really use them between multiple threads in a reliable fashion. If one thread is running a statement and you then try to use the connection on a different thread, bad things will happen. Even more justification to just give each thread its own connection and let it get on with what it wants to do, without having to engage in some kind of mutex synchronization (a bottleneck that removes some of the attraction of multithreading, too!).
Related
I have two threads in java application. The first thread runs the JDBC connection logic. The second one is listening to user's command.
public static void main ...
private Connection c; // this is JDBC connection visible to both Thread 1 and 2
Thread thread1 = new Thread(new Runnable() {
public void run() {
// logic to execute SQL statements on Connection c
}
);
Thread thread2 = new Thread(new Runnable() {
public void run() {
// Here i try to execute connection close on user's demand.
c.close();
// this command executes with no error,
// but the connection doesnt close immediately.
// The SQL statements in thread 1 somehow waits to finish,
// and only then will the connection stop.
// How to forcefully and abruptly stop the connection ?
}
);
How to forcefully and abruptly stop the connection ?
You could try calling c.close() in the 2nd thread, but:
JDBC connection objects are not thread-safe1, so the Java-side behavior is unspecified.
AFAIK, the JDBC spec doesn't say what will happen on the database server if a database connection is closed while a request is in progress. It is not clear if the request is terminated immediately or a bit later (with a transaction rollback or not).
So my advice would be don't do this. Find another way to do what you are trying to do.
(If you want advice on other ways, tell us the real problem you are trying to solve here rather than your roadblock with your attempted solution to the problem.)
1 - More precisely, they are not required to be thread-safe by the JDBC spec. They might actually be (sufficiently) thread-safe in some driver implementations, but ... only if the vendor docs say so. From various sources, at least Oracle DB and Derby support multiple threads sharing a logical JDBC connection, though they seem to support different models.
I don't think you can this way. But you can exit the whole JVM forcely:)
I have a multithreaded application which uses OracleDriver.defaultConnection() to connect to the database.
This line of code is used in multiple code blocks which are accessed by different threads.
I am getting the error : Java Thread Deadlock detected
This is a sample piece of code :
private void function1() {
//something here
Connection conn = OracleDriver.defaultConnection();
// something here
conn.execute();
conn.close();
}
Second piece of code which is in a separate class :
private void function2() {
//something here
Connection conn = OracleDriver.defaultConnection();
// something here
conn.execute();
conn.close();
}
How do I make this connection "thread-safe"?
Also, I read that defaultConnection() returns a static object. So can this be caused due to the connection being closed by one thread while the other thread is using it?
I cannot use any connection method which requires me to input the database username and password.
Thanks in advance!
Java provides many ways for dealing with concurrency(synchronized, ReentrantLock, ReadWriteLock)
Considering the documentation which says:
The oracle.jdbc.OracleDriver class defaultConnection() method is an Oracle extension and always returns the same connection object.
Since it always returns the same connection object you can synchronize on it:
Connection conn = OracleDriver.defaultConnection();
synchronized (conn) {
// something here
conn.execute();
}
However you would need to remove all conn.close() calls due to:
If you do call the close() method, be aware of the following: All connection instances obtained through the defaultConnection() method, which actually all reference the same connection object, will be closed and unavailable for further use, with state and resource cleanup as appropriate. Executing defaultConnection() afterward would result in a new connection object.
Even though the connection object is closed, the implicit connection to the database will not be closed.
I have created a Database class which uses a static connection object in order to be used in common between instances of itself. my question is that is there any problem with this approach or not?
class Database {
private static Connection connection = null;
public Database() {
if(connection == null){
...
connection = DriverManager.getConnection(...);
...
}
}
}
If you are going to have many (hundreds) of queries per second then implementing a connection pool is the way to go. See the answer to this question for more details. However, if you a Java novice (we all were one day!) then I don't imagine you will be needing this requirement, and probably will struggle to implement it.
Instead, the simple pattern of creating a new connection if required, and then closing it when finished will be the best way to go forward for you. Below is a modified version of your Database class which I think is a good way to move forward.
class Database {
private Connection con = null;
private final String connectionString;
public Database(String connectionString) {
this.connectionString = connectionString;
}
public void connect() throws SQLException {
if (con != null // if the connection exists
&& !con.isClosed() // and has not been closed
&& con.isValid(0)) { // and appears to be functioning (with a test timeout of 0ms)
return; // skip connection creation
}
// create the connection
con = DriverManager.getConnection(connectionString);
}
public void testFunction() {
try {
connect();
// .. do some stuff with the connection ..
} catch (Exception e) {
// log or otherwise deal with the error
} finally {
try {
con.close();
} catch (Exception e) {
System.err.println("Failed to close connection: " + e.toString());
}
}
}
}
Some things to note about this solution:
It is not very efficient - creating a new connection always takes more time than using an existing one
This class if not thread safe - if you need this requirement, I recommend using a thread pool. However, if you create a new instance of this class per thread then it will be thread safe (as there is not static connection to worry about!)
It does do the job - certainly for simple cases. I use the model for a relatively low volume database which has approx 50-100 connections made/closed per minute and it does not add a noticeable lag
It is very robust - nothing is safer than opening and closing a connection per query. You are guaranteed to be able to handle a connection failure per query, and the connection will always be closed (unless it already has been).
Disclaimer The solution above is not a particularly amazing solution. However, I believe it is simple to implement and a good way for a Java novice to get to know the ropes before jumping into external libraries.
There is nothing wrong with creating an object to manage your connections, however, connections should be opened and closed and can be used in multi-threaded environments, so having a static connection is not a good idea. For a method that needs a connection, get a connection use it, close it. Even if you are not using it in a multi-threaded environment, the connection can time-out, then you need to constantly check if the connection is up and available, instead of just saying, get me a connection, use the connection, close it.
I am passing Resultset object to each thread. Each thread is connecting to the database and inserting data. Untill thread 110 it is working fine. After it crosses 111 thread it throws the above exception.
I am using oracle 11g.
My sample Thread code is:
class MyThreadClass implements Runnable
{
public Connection connection;
public Statement statement2;
public ResultSet rs2;
public String cookie;
public MyThreadClass(ResultSet rs1)
{
rs2=rs1;
}
public void run()
{
try
{
cookie=rs2.getString("COOKIE");
driver = "oracle.jdbc.driver.OracleDriver";
url = "jdbc:oracle:thin:#127.0.0.1:1521:xx";
/* connection
statement2.executeUpdate("INSERT INTO visit_header VALUES ('"+cookie+"')");
}
I am not getting how to handle this exception.
Your multi-threaded application is opening too many Connections/Sessions. Hence, the listener is dropping and blocking new connections for a while.
Check your DB resource usage first:
SELECT * FROM v$resource_limit WHERE resource_name IN ('processes','sessions');
Check to see if your MAX_UTILIZATION for either your Processes or Sessions is getting too close to the LIMIT_VALUE. If yes, you should either:
Use DB Connection pooling to share Connection objects between threads. Or,
Increase the number of processes/sessions that Oracle can service simultaneously.
Actually, Connection Pooling (#1) should always be done. An application cannot scale up otherwise. Check Apache Commons DBCP for details. For #2, open a new SQL*Plus session as SYSTEM and run:
ALTER system SET processes=<n-as-per-number-of-threads> scope=spfile;
to increase backend concurrency. Then RESTART the Database. IMPORTANT!
I guess the database just don't accept more connections from your host. If I understand your question right you are making maybe 100 threads which each connects to the database in short time. Maybe you don't even close the connection correctly, or the accesses are lasting so long that a huge amount of connections are opened. The database have a limit to which it accepts connections.
You should definitely reduce the number of connections by some clever technique. Maybe reduce the number of concurrent threads and/or use a connection pool.
Try this solution at your end. It worked for me.
Close the connection in try/catch block and just after closing the connection,
write-
Thread.sleep(1000);
In this case you can write it as-
finally {
try {
if (conn != null && !conn.isClosed())
{
conn.close();
Thread.sleep(1000);
}
}
catch (SQLException e) {
e.printStackTrace();}
}
Our standard code section for using JDBC is...
Connection conn = getConnection(...);
Statement stmt = conn.conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet rset = stmt.executeQuery (sqlQuery);
// do stuff with rset
rset.close(); stmt.close(); conn.close();
Question 1: When using Connection Pool, should one close the Connection at the end? If so, isn't the purpose of pooling lost? And if not, how does the DataSource know when a particular instance of Connection is freed up and can be reused? I am a little confused on this one, any pointers appreciated.
Question 2: Is the following method anything close to standard? Looks like an attempt to get a connection from the pool, and if DataSource cannot be established, use the old fashioned DriverManager. We are not even sure which part is getting executed at runtime.
Repeating the question above, should one close the Connection coming out of such a method?
synchronized public Connection getConnection (boolean pooledConnection)
throws SQLException {
if (pooledConnection) {
if (ds == null) {
try {
Context envCtx = (Context)
new InitialContext().lookup("java:comp/env");
ds = (DataSource) envCtx.lookup("jdbc/NamedInTomcat");
return ds.getConnection();
} catch (NamingException e) {
e.printStackTrace();
}}
return (ds == null) ? getConnection (false) : ds.getConnection();
}
return DriverManager.getConnection(
"jdbc:mysql://"+ipaddy+":"+dbPort +"/" + dbName, uName, pWord);
}
Edit: I think we are getting the pooled connection since we do not see a stack trace.
When using Connection Pool, should one close the Connection at the end? If so, isn't the purpose of pooling lost? And if not, how does the DataSource know when a particular instance of Connection is freed up and can be reused? I am a little confused on this one, any pointers appreciated.
Yes, certainly you need to close the pooled connection as well. It's actually a wrapper around the actual connection. It wil under the covers release the actual connection back to the pool. It's further up to the pool to decide whether the actual connection will actually be closed or be reused for a new getConnection() call. So, regardless of whether you're using a connection pool or not, you should always close all the JDBC resources in reversed order in the finally block of the try block where you've acquired them. In Java 7 this can be further simplified by using try-with-resources statement.
Is the following method anything close to standard? Looks like an attempt to get a connection from the pool, and if DataSource cannot be established, use the old fashioned DriverManager. We are not even sure which part is getting executed at runtime. Repeating the question above, should one close the Connection coming out of such a method?
The example is pretty scary. You just need to lookup/initialize the DataSource only once during application's startup in some constructor / initialization of an applicationwide DB config class. Then just call getConnection() on the one and same datasource throughout the rest of application's lifetime. No need for synchronization nor nullchecks.
See also:
Is it safe to use a static java.sql.Connection instance in a multithreaded system?
Am I Using JDBC Connection Pooling?
The pools typically return you a wrapped Connection object, where the close() method is overridden, typically returning the Connection to the pool. Calling close() is OK and probably still required.
A close() method would probably look like this:
public void close() throws SQLException {
pool.returnConnection(this);
}
For your second question, you could add a logger to show whether the bottom block ever runs. I would imagine though you'd only want one way or the other for the configuration of your database connections. We solely use a pool for our database accesses. Either way, closing the connection would be pretty important to prevent leaks.
Actually, the best approach to connection management is to not farm them out to any code anywhere.
Create a SQLExecutor class that is the one and only location which opens and closes connections.
The entire rest of the application then pumps statements into the executor rather than getting connections from the pool and managing (or mismanaging them) all over the place.
You can have as many instances of the executor as you want, but no one should be writing code that opens and closes connections on its own behalf.
Conveniently, this also lets you log all your SQL from a single set of code.