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.
Related
Everywhere we see that the Statement.close() is 'handled' by eating up the exception that it throws. What are the cases where it can throw an exception in the first place? And what does it mean for the connection with which this statement was created?
In other words, when does statement.close() throw an exception and would the connection still be 'healthy' to be used for creating new statements?
Also, what happens if resultset.close() throws?
First, consider what the close() method might need to do, and what might cause an exception.
E.g. a PreparedStatement might have created a stored procedure, which needs to be deleted by the close() method. executeQuery() may have opened a cursor, which is used by the ResultSet, and close() needs to close that cursor.
Exception could of course be an internal error, but is most likely a communication error, preventing the close operation from succeeding.
So, what does that mean? It means that resources are not being explicitly cleaned up. Since your operation is already complete, it's generally ok to ignore those close() exceptions, since resources will be reclaimed eventually anyway.
However, since the cause is probably a communication error, the connection is likely broken, which means that you'll just get another exception on whatever you try next, making it even less likely that your handling of the close() exception matters.
To be safe, an exception means that something is wrong, and unless you examine the exception to understand how bad it is, you should abort whatever you're doing. A new connection should be established if you want to try again.
But, as already mentioned, ignoring close() exceptions aren't really a big issue. It may lead to resource leaks, but if the problem is bad, you're just going to get another exception on your next action anyway.
Simplest case for such an exception: the connection, that handled the statement is closed before you are trying to close the statement or if the statement was closed -somehow- already. speaking for jdbc, the connection should be healthy.
In general: As Peter stated, if the documentation of the driver does not contain any recommendations how to handle such an exception, you can only log or debug it. maybe you could re-establish the connection to be sure it is healthy.
When you close a statement, a lot of things can happen. These basic things can happen when closing a statement:
The open result set - if any - is closed, which may require communication to the database
The statement handle on the database server is released, which requires communication to the database
Given this involves communication to the database, all kinds of errors can occur: file system errors, network connection problems, etc. These may be safe to ignore, but could also indicated something very wrong with your application or database.
A secondary effect of a statement close can be a transaction completion (a commit or rollback). This could - for example - happen in auto-commit mode when you execute a data-modifying statement that produces a result set: the transaction ends when the result set is closed by the close of the statement. If this transaction commit fails, and you ignore it, your application may have just had a data-loss event (because the data was not persisted), and you just went ahead and ignored it.
In other words: you should not just ignore or swallow exceptions from Statement.close() unless you are absolutely sure there will be no detrimental effects. At minimum log them so you can trace them in your logs (and maybe define alerts on the number of exceptions logged), but always consider if you need to wrap them in application-specific exceptions and throw them higher up the call chain for handling, or - for commit failures - if you need to retry anything.
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();
}
How would you detect a lost connection using JDBC in a reliable and an efficient way? Currently I'm using a Vertica JDBC driver. I don't think I can use connection pools as I need to control to which node I'm connected at all times. Things I thought of so far:
Assume SQLException is a lost connection. Seems unreliable.
Check ex.getCause and look for a socket exception. Not sure if checking cause is a good practice.
Check error code which I know is a case for a lost connection. Also seems a bit unreliable.
Edit:
I've tried isValid and isClosed. isValid throws an exception and isClosed always returns false regardless.
From version 1.6, you can theoretically use the Connection.isValid method but I am not sure if every vendor supports it. An other alternative is using a connection pool which manages connections and you get the connection from them and release it when you don't need it. Connection pools take the responsiblity of maintaining connections and they always provide valid connections.
I am building DB class, in the constructor I want to establish the connection with database, so that static dbLink is accessible by the rest of the functions inside that class. Is that a good approach?
As to the concrete question, surely it's legal to throw exceptions in a constructor. There's no other sane way to prevent the "DB class" instance from being used with a broken connection.
As to the concrete functional requirement, you've another major problem. You should not be creating a DB connection in the constructor of a "DB class" and surely not make it static. This indicates that you're intending to keep the connection open as long as the instance of the "DB class" lives in Java's memory. This is in turn a very bad idea. The connection should instead be created in the very same try block as where you're executing the SQL query/queries. The connection should also be closed in the finally block of that try block. This prevents resource leaking in long term which would otherwise cause your application to crash because the DB server times out the resource because it's been open for too long, or runs out of resources because too many connections have been opened.
See also:
How often should Connection, Statement and ResultSet be closed in JDBC?
JDBC MySql connection pooling practices to avoid exhausted connection pool
When my app loses connection, how should I recover it?
My suggestion would be to provide a connect() method in your class that will throw exceptions and let your class instantiate without exceptions.
"Hello, yes, it is normal to throw an exception from a constructor. In fact, throwing an exception is
the only way that a constructor can fail.
However, you should be cautious about throwing any exception from a constructor that is a subclass of RuntimeException. The Java compiler does not force the calling code to handle such exceptions, and therefore they impose some additional risk. It is okay to use them sometimes, but be careful."
From here: http://en.allexperts.com/q/Java-1046/normal-throw-exception-constructor.htm
Typically, creating a connection object of some sort does not actually establish a connection, it just sets up the connection to be made. It makes more sense to have a connect() method which establishes the connection or throws an exception if it cannot.
I don't think it makes sense to have the constructor establish a connection, so it shouldn't throw any exceptions.
I have a Data base connection pool. There are consumers who take connection from that pool.
But i cant trust those consumers because lot of them are not returning my connection back. Hence the pool starves and many consumers are forced too wait for infinite.
for example:
class Consumer{
void someMethod(){
Connection con=Pool.getConnection();
//some bloody steps which throws exception
con.goodBye();//giving back the connection to the pool
}
}
Because of the exception and may be because of arrogance the connection is not given back always. I have no way to restrict the usage of Pool api in the consumers' class.
How can i get my connection back?.(I have no way to force the Consumer)
I believe there is no fool proof solution for this(May be im not that smart). Still can any one can come up with a pretty good solution.
One solution which i got is checking whether any exception occurs in the Consumer class, if Exception occurs then take back the connection force fully.
Or is there any new revolutionary DBPool design pattern which are not very popular for this type of typical scenarios(even though i think that my case is very generic, any one can forget to give back the connection back to the pool.)
That's bad client code. The code should handle the case of an exception and close the connection when done.
There's no way for you to know from your code if that's not being done, though. It's the client code's fault and problem if it doesn't do that.
Having a sane timeout is the only way to limit this, but it still does not "solve" it, ultimately.
--
You mention in comments that this pool is shared among multiple clients. That shifts the responsibility back to you, of course.
Can you limit each client to only using X connections at once? This way, at least they can only tie up so many at one time.
Otherwise, you could create separate pools per client. That sort of just moves the problem down the stack, but might be appropriate, depending on the logistics involved.
Do not return connection objects, return proxy objects representing connections instead. These proxy objects, when finalized, should say goodbye to the connection they stand for. If a proxy is not properly closed, it will eventually be garbage-collected, and adjust the connection state at this time.
Two issues here. First, the time before GC is unpredictable. Better than forever, but still can be very long. Second, be aware of side effects of complex calls in the finalizer, object resurrection in particular. There are some rare but ugly scenarios that prevent objects to be collected at all.
why don't you look at using WeakReference, here you can adjust your code to return a weak reference to a connection, when the thread using the connection dies, the object will have no reference (except from your WeakHashMap), you can then periodically identify these objects and call the goodBye method using a thread.
here is an article which can help you understand this better.
.net also has a WeakReference class which behaves very similar to this.
Have you tried catching the exception and closing the connection in the catch clause?
class Consumer{
void someMethod(){
Connection con=Pool.getConnection();
try{
//some bloody steps which throws exception
}catch(Exception e){
con.goodBye();
}
con.goodBye();//giving back the connection to the pool
}
}
Edit: you could also use a finally block to remove the redundant code and make sure your connection gets closed in every case. I am assuming this is java code, no experience with C#.
The only way I can think of is not to give the consumers access to the connection pool directly, but have your own list of connections. Then reclaim the connection after a timeout, say 60 seconds.