commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <dirk.verbe...@pandora.be>
Subject Re: NullPointer with Oracle 9 driver
Date Mon, 24 Nov 2003 22:33:52 GMT
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(ScrollableResultSet.java:14
> 9)
>         at
> org.apache.commons.dbcp.DelegatingResultSet.close(DelegatingResultSet.ja
> va:193)
>         at
> org.apache.commons.dbcp.DelegatingResultSet.close(DelegatingResultSet.ja
> va:193)
>         at
> org.apache.commons.dbcp.DelegatingPreparedStatement.passivate(Delegating
> PreparedStatement.java:298)
>         at
> org.apache.commons.dbcp.DelegatingPreparedStatement.close(DelegatingPrep
> aredStatement.java:185)
>         at
> com.pcmsgroup.v21.star.framework.persistence.BaseDbDAO.releaseResources(
> BaseDbDAO.java:205)
>         at
> com.pcmsgroup.v21.star.persistence.logon.LogonDbDAO.fetchByLogonName(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(LogonService.jav
> a:52)
>         at
> com.pcmsgroup.v21.star.application.logon.LogonCtrl.process(LogonCtrl.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(RequestProcessor.java:
> 274)
>         at
> org.apache.struts.action.ActionServlet.process(ActionServlet.java: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.internalDoFilter(Applica
> tionFilterChain.java:247)
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:193)
>         at
> com.pcmsgroup.v21.star.application.logon.LogonFilter.doFilter(LogonFilte
> r.java:168)
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(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.releaseResources
> 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


Mime
View raw message