This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes JDBC and the fly likes Connection Closed Errors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Connection Closed Errors" Watch "Connection Closed Errors" New topic
Author

Connection Closed Errors

Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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.


SCJP Tipline, etc.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30076
    
149

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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?
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30076
    
149

Corey,
I agree it won't harm matters. Note that it won't protect you against "ctale connection" errors. Which may not be an issue as you aren't having that problem at the moment.

A longer term solution would be to get a "fresh" connection from the pool each time it is needed and let the pool do its job. Connection pool code is optimized for this kind of thing.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Connection Closed Errors
 
Similar Threads
ServeltContextListener for DataSource
Web application goes extremely slow with more than 5 users logged in
Tomcat 5.5 connection pooling
A question about NoInitialContextException:
Passing a DataSource from JNDI to my DAO through Session Bean