Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: 5 Mar 2003 16:49:03 -0000
Message-ID: <20030305164903.21967.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 17678] New:  -
    DBCP Fails silently in many cases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17678>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17678

DBCP Fails silently in many cases

           Summary: DBCP Fails silently in many cases
           Product: Commons
           Version: 1.4 Final
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Dbcp
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: flawlor@athensgroup.com


One problem with much of the pooling code (and also other Jakarta code) is its 
unfortunate �fail silently� behavior.  What this means is that when errors or 
unexpected conditions are detected, the code just �swallows� the error � no 
exception, no logging, nada.  Needless to say this is rarely good for the 
application and can make debugging very difficult.

Looking through the code I saw a number of places where the code just swallows 
errors.  Some of these were important things I felt I wanted to know about.  
The pooling code not only can throw exceptions, but also has the JDBC trace 
log available to it (DriverManager.setLogWriter()).  Unfortunately much of the 
code does neither.  We modified the code in several places to throw (or at 
least not swallow) exceptions, especially those related to connection close 
problems (e.g., GenericObjectPool.returnObject()(2 places), 
PoolableConnectionFactory.destroyObject(), DelegatingConnection.checkOpen() 
should check the real connection, DelegatingConnection.activate() should check 
for alrady activated, DelegatingConnection.passivate() should check for 
already closed, and PoolableConnection.close() should check for already 
closed).

I'm sure there are other places.  I just happened to be focusing on close().

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org