Fw: What is a Dirty Connection (using -Djdbc.debug=true)
I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about dirty connections. (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion wraps the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a dirty connection is one that has an associated open Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly close a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a dirty connection means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or closed). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly close these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to close those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing a Connection is supposed to also close any associated Statements, ResultSets, etc. However, the Oracle JDBC driver does not. You need to explicitly close the ResultSet, then the Statement, then the Connection. So in summary, I will answer your questions individually now with a short answer, below: Q:What is a Dirty Connection (when using -Djdbc.debug=true)? A:A connection with unclosed resources lying around. Q:What causes it? A:Not explicitly closing the resources. Q:What repercussions does it have? A:It can crash the database server. Q:Is a Dirty Connection a bad thing? A:Yes. Q:What can we do to avoid it (if anything)? A:Explicitly close all resources -- ResultSets, Statements, etc. Q:Are there any settings that control when and if they are cleaned up? A:If you are using pooled connections, perhaps the inactivity-timeout attribute in the data-sources.xml file can help -- I don't know for sure. Q:Are they cleaned up at all? A:As far as I can tell, no. A very long post -- I hope you don't mind, and I hope it can help you. Good Luck, Avi. -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
Re: What is a Dirty Connection (using -Djdbc.debug=true)
I don't see how this helps with your question at all. You were asking about CMP, and he is talking about BMP. I too have the problems you are encoutering with CMP and stale connections being left over. I'd love to hear of solutions to this problem. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 8:25 AM Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about dirty connections. (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion wraps the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a dirty connection is one that has an associated open Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly close a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a dirty connection means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or closed). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly close these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to close those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing a Connection is supposed to also close any associated Statements, ResultSets, etc. However, the Oracle JDBC driver does not. You need to explicitly close the ResultSet, then the Statement, then the Connection. So in summary, I will answer your questions individually now with a short answer, below: Q:What is a Dirty Connection (when using -Djdbc.debug=true)? A:A connection with unclosed resources lying around. Q:What causes it? A:Not explicitly closing the resources. Q:What repercussions does it have? A:It can crash the database server. Q:Is a Dirty Connection a bad thing? A:Yes. Q:What can we do to avoid it (if anything)? A:Explicitly close all resources -- ResultSets, Statements, etc. Q:Are there any settings that control when and if they are cleaned up? A:If you are using pooled connections, perhaps the inactivity-timeout attribute in the data-sources.xml file can help -- I don't know for sure. Q:Are they cleaned up at all? A:As far as I can tell, no. A very long post -- I hope you don't mind, and I hope it can help you. Good Luck, Avi. -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
Re: What is a Dirty Connection (using -Djdbc.debug=true)
Patrick, It helped in that noone else responded, and it points to the fact that something, either a statement or result set, isn't getting closed (if container-managed connections are dealt with the same as user-managed connections, which I'm assuming is true). I agree with you that he's talking about BMP, but the underlying connection stuff should be the same (except for the fact that the container is handling it instead of us, in which case you'd think it would be sure to close everything, but it doesn't look like it is). Some suggestions have been to move from CMP to BMP, but in my opinion that's taking a step backwards. It sounds like there's a problem in the container's handling of connections, but we have yet to hear anything from anyone with any code-level knowledge of Orion. Magnus, is this an issue? and if so, is it going to be fixed in Orion 1.5.4, and if so, when will we see it? Jeff. On Tue, 29 Jan 2002 11:28:18 -0800 Patrick Lightbody [EMAIL PROTECTED] wrote: I don't see how this helps with your question at all. You were asking about CMP, and he is talking about BMP. I too have the problems you are encoutering with CMP and stale connections being left over. I'd love to hear of solutions to this problem. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 8:25 AM Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about dirty connections. (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion wraps the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a dirty connection is one that has an associated open Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly close a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a dirty connection means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or closed). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly close these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to close those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing a Connection is supposed to also close any associated Statements, ResultSets, etc. However, the Oracle JDBC driver does not. You need to explicitly close the ResultSet, then the Statement, then the Connection. So in summary, I will answer your questions individually now with a short answer, below: Q:What is a Dirty Connection (when using -Djdbc.debug=true)? A:A connection with unclosed resources lying around. Q:What causes it? A:Not explicitly closing the resources. Q:What repercussions does it have? A:It can crash the database server. Q:Is a Dirty Connection a bad thing
Re: What is a Dirty Connection (using -Djdbc.debug=true)
Yes, sounds like Orion isn't closing the Statements and ResultSets that it uses for CMP, instead it is just closing the Connection. If that is the case, either an update in the Oracle JDBC driver or an update with Orion would fix the bug. Let's hope one of the two comes out soon, because how it is now is very bad. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 2:10 PM Subject: Re: What is a Dirty Connection (using -Djdbc.debug=true) Patrick, It helped in that noone else responded, and it points to the fact that something, either a statement or result set, isn't getting closed (if container-managed connections are dealt with the same as user-managed connections, which I'm assuming is true). I agree with you that he's talking about BMP, but the underlying connection stuff should be the same (except for the fact that the container is handling it instead of us, in which case you'd think it would be sure to close everything, but it doesn't look like it is). Some suggestions have been to move from CMP to BMP, but in my opinion that's taking a step backwards. It sounds like there's a problem in the container's handling of connections, but we have yet to hear anything from anyone with any code-level knowledge of Orion. Magnus, is this an issue? and if so, is it going to be fixed in Orion 1.5.4, and if so, when will we see it? Jeff. On Tue, 29 Jan 2002 11:28:18 -0800 Patrick Lightbody [EMAIL PROTECTED] wrote: I don't see how this helps with your question at all. You were asking about CMP, and he is talking about BMP. I too have the problems you are encoutering with CMP and stale connections being left over. I'd love to hear of solutions to this problem. -Pat - Original Message - From: Jeff Hubbach [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 8:25 AM Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about dirty connections. (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion wraps the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a dirty connection is one that has an associated open Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly close a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a dirty connection means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or closed). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly close these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to close those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing
What is a Dirty Connection (using -Djdbc.debug=true)
I already asked this question in a different thread but didn't get a reply, so let's try again. What is a Dirty Connection (when using -Djdbc.debug=true)? What causes it and what repercussions does it have? Is a Dirty Connection a bad thing, and if so, what can we do to avoid it (if anything)? Are there any settings that control when and if they are cleaned up? are they cleaned up at all? I appreciate any information you may have. Thanks in advance, Jeff.
