This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
In the past, I've worked on an application which uses JDBC to connect to a SQL Server database. Recently, some users have started getting errors that read "DSRA9110E: Connection is closed." The odd part about this is that it's only a couple users (that we know of) that are receiving the error message and they get it intermittently. No single operation seems to be causing it. It just happens periodically. So, in effect, the exact same operation, such as viewing a specific page might work one time but result in an error, the next time.
I'm really wondering if there's something wrong in the way that the database connection is being retrieved and used. Below is a condensed version of the code being used. In general, it seems to work, but I wonder if there's a risk of something going wrong and some users are now hitting that.
Unfortunately, we've been entirely unable to reproduce the error "in house."
Most of the methods in the application tend to follow this general flow. Get a new connection from the manager - send that connection to a DAO object that actually hits the database - and then close the connection when we're done. Is there something we're doing wrong such that we risk the connection being close prematurely?
Honestly, I'm a bit baffled by the nature of the error in that it only seems to happen occasionally.
Corey, Two things jump out at me about the code. I don't think either of them are related to the problem, but I'll mention them anyway.
1) How does the data source get initialized in the first place? Is there static code somewhere else that calls the constructor? 2) Is the call to DBConnectionManager.close() in a finally block? I don't see one, but you might have taken out to simplify the post.
Now on to your post. A connection can be closed for a variety of reasons including a timeout or network problems. So unfortunately, it could be almost anything.
Thanks, Jeanne. We still don't know exactly what the issue is, but I've been trying to help find a solution.
Now that you mention it, though, I have absolutely no idea how the DataSource is being initialized. The methods used to get the connection are static methods so calling those would not require the constructor to be invoked. Unfortunately, I'm only vaguely related to this project so I don't know all the inner workings. Obviously, the DataSource is being intialized somewhere along the way, though, because the database connection is working. Odd, but I'll look into it. I'm sure there's an explanation.
However, in order to try to fix the problem of a prematurely closed connection, I've suggested that they modify the code to look something more like this (kind of a modified version of a singleton pattern):
I'm hoping that, by modifying the code in such a way, a check will be done every time a connection is to be used to ensure that the connection is open. Looking through the existing code, it looks like a single connection was being opened and then being used for a number (sometimes a rather large number) of operations. The reason I modified the connection member to be private was just to force the sublcasses that would use it to go through the getConnection() method.
As I told the folks working on this project - I don't know that it'll really fix the problem. It'll add a small amount of overhead, but it shouldn't really hurt anything.
Does that make sense? Any thoughts on this approach?
Joined: Dec 20, 2001
Originally posted by Corey McGlone: Now that you mention it, though, I have absolutely no idea how the DataSource is being initialized.
Just as a bit of follow-up - I did find where the DBConnectionManager class is being instantiated. I don't know that I agree with how it's being done but, suffice it to say, an instance of the class is always created and, therefore, the constructor does execute properly.
author & internet detective