Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
From: "Simon Matic Langford" <simon.langford@pcmsgroup.com>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: RE: NullPointer with Oracle 9 driver
Date: Wed, 26 Nov 2003 14:56:12 -0000
Message-ID: <005501c3b42d$6ed77d90$0557555a@PCMSDEV011>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3FC28750.309@pandora.be>

have done 

> -----Original Message-----
> From: Dirk Verbeeck [mailto:dirk.verbeeck@pandora.be] 
> Sent: 24 November 2003 22:34
> To: Jakarta Commons Users List
> Subject: Re: NullPointer with Oracle 9 driver
> 
> 
> It looks like a bug or at least something to be improved.
> Your analysis is correct and reverting the change will 
> correct the problem.
> I don't know why Rodney committed this change but we better 
> make sure we don't 
> break anything if we undo the change.
> 
> JUnit tests are needed to show the error and prove the 
> correctness of the 
> solution.
> 
> Anyway please create a bugzilla issue to track the problem.
> 
> -- Dirk
> 
> Simon Matic Langford wrote:
> 
> > Hi,
> > 
> > I've recently upgraded to the latest version of Tomcat 
> (4.1.29), which
> > includes DBCP 1.1, over 1.0 in previous versions.
> > 
> > On starting my application and attempting to logon to it, 
> it falls over
> > with a NullPointerException, included here:
> > java.lang.NullPointerException
> >         at
> > 
> oracle.jdbc.driver.ScrollableResultSet.close(ScrollableResultS
> et.java:14
> > 9)
> >         at
> > 
> org.apache.commons.dbcp.DelegatingResultSet.close(DelegatingRe
> sultSet.ja
> > va:193)
> >         at
> > 
> org.apache.commons.dbcp.DelegatingResultSet.close(DelegatingRe
> sultSet.ja
> > va:193)
> >         at
> > 
> org.apache.commons.dbcp.DelegatingPreparedStatement.passivate(
> Delegating
> > PreparedStatement.java:298)
> >         at
> > 
> org.apache.commons.dbcp.DelegatingPreparedStatement.close(Dele
> gatingPrep
> > aredStatement.java:185)
> >         at
> > 
> com.pcmsgroup.v21.star.framework.persistence.BaseDbDAO.release
> Resources(
> > BaseDbDAO.java:205)
> >         at
> > 
> com.pcmsgroup.v21.star.persistence.logon.LogonDbDAO.fetchByLog
> onName(Log
> > onDbDAO.java:149)
> >         at
> > com.pcmsgroup.v21.star.domain.logon.Logon.logon(Logon.java:95)
> >         at
> > 
> com.pcmsgroup.v21.star.service.logon.LogonService.logon(LogonS
> ervice.jav
> > a:52)
> >         at
> > 
> com.pcmsgroup.v21.star.application.logon.LogonCtrl.process(Log
> onCtrl.jav
> > a:87)
> >         at
> > 
> com.pcmsgroup.v21.star.framework.application.BaseCtrl.execute(
> BaseCtrl.j
> > ava:180)
> >         at
> > 
> org.apache.struts.action.RequestProcessor.processActionPerform
> (RequestPr
> > ocessor.java:484)
> >         at
> > 
> org.apache.struts.action.RequestProcessor.process(RequestProce
> ssor.java:
> > 274)
> >         at
> > 
> org.apache.struts.action.ActionServlet.process(ActionServlet.j
> ava:1482)
> >         at
> > 
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
> >         at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> >         at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> >         at
> > 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(Applica
> > tionFilterChain.java:247)
> >         at
> > 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilt
> > erChain.java:193)
> >         at
> > 
> com.pcmsgroup.v21.star.application.logon.LogonFilter.doFilter(
> LogonFilte
> > r.java:168)
> >         at
> > 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(Applica
> > tionFilterChain.java:213)
> >         ...
> > 
> > I've looked around the web, and in your CVS, and think that 
> this is a
> > bug.
> > 
> > The code in
> > 
> com.pcmsgroup.v21.star.framework.persistence.BaseDbDAO.release
> Resources
> > is as follows:
> > 
> >   public final void releaseResources(Connection connection,
> > PreparedStatement ps, ResultSet rs) throws PersistenceException
> >   {
> >     try
> >     {
> >       if (rs != null)
> >       {
> >         rs.close();
> >       }
> >       if (ps != null)
> >       {
> >         ps.close();
> >       }
> >       if (connection != null)
> >       {
> >         // get the Factory
> >         ConnectionFactory factory = ConnectionFactory.getInstance();
> >         // turn the Connection back to pool
> >         factory.releaseConnection(connection);
> >       }
> >     }
> >     catch (SQLException sqle)
> >     {
> >       thisLog.error("Failed to release resources", sqle);
> >     }
> >     catch (Exception e)
> >     {
> >       thisLog.error("Failed to release resources", e);
> >       throw new PersistenceException(e);
> >     }
> >   }
> > 
> > As you can see, we close ResultSet, PreparedStatement and 
> Connection in
> > the reverse order of that which we
> > got them in. On DBCP 1.0, this used to work fine. According 
> to the JDK
> > API docs: "When a Statement object is 
> > closed, its current ResultSet object, if one exists, is 
> also closed."
> > Thus closing the statement after closing the
> > result set is safe.
> > 
> > However, for DBCP 1.1, a change was made to 
> DelegatingPreparedStatement
> > (version 1.6 to 1.7), to "ensure 
> > PreparedStatment can only be closed once", which entailed changing:
> > 
> >      public void close() throws SQLException {
> >          passivate();
> >          _stmt.close();
> >      }
> > 
> > to:
> > 
> >      public void close() throws SQLException {
> >          _stmt.close();
> >          passivate();
> >      }
> > 
> > I believe this has introduced my problem and is a bug. As 
> now, following
> > the logic:
> > 
> > - The statement is closed, and in accordance with the JDK docs, the
> > result set is closed.
> > - The passivate method is then called, which calls 
> ResultSet.close on
> > the underlying result set,
> >   regardless of whether it has been closed already.
> > - This causes the underlying result set, which is already 
> closed to try
> > to close again, thus
> >   the NullPointer.
> > 
> > I couldn't spot this in the bug reports, so could someone 
> answer if this
> > is a bug or not, or is there
> > something I am doing wrong, or should this be directed at 
> the developers
> > list? I don't believe I should 
> > quietly catch Exception's in the close() methods as per 
> your examples,
> > as I'd really like to know 
> > if there are problems!
> > 
> > Thanks
> > 
> > Simon
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 


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