ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: Statements being closed when they shouldn't be
Date Fri, 27 Oct 2006 19:30:53 GMT
Yeah, let's open a JIRA issue....

JEFF:  Could this be the same problem with the prepared statement caching
when logging is enabled?


On 10/27/06, Christopher.Mathrusse@sybase.com <
Christopher.Mathrusse@sybase.com> wrote:
>  Hi Clinton,
> I've run into a bit of a snag in the SqlExecutor class, closeStatement
> method. (Line 501) It seems that this class caches statements within the
> session object. In the closeStatement method there is an evaluation:
>     if (!session.hasPreparedStatement(ps)) {
>       if (ps != null) {
>         try {
>           ps.close();
>         } catch (SQLException e) {
>           // ignore
>         }
>       }
>     }
> The problem that I'm seeing is that the PreparedStatement is being closed
> every time. This is due to the fact that the actual PreparedStatement is
> wrapped within a PreparedStatementLogProxy object. When the evaluation is
> made above, session.hasPreparedStatement(ps), the session is asking the
> preparedStatements HashMap if it contains a value, namely the
> PreparedStatementLogProxy. When the map iterates through the objects it
> contains the equals() method is invoked on each object. This is where the
> problem lies.
> Invoking equals() causes the invoke method of the PreparedStatementLogProxy
> to intercept the call. Evaluations are made within this method until the
> following method is invoked, allowing the underlying equals method on the
> PreparedStatement to be invoked.
> *return* method.invoke(statement, params);
> The problem here is that the actual PreparedStatement is being passed in
> for comparison with an instance of PreparedStatementLogProxy. This always
> results in evaluating to false. Even if you were to compare an instance of
> the Proxy with itself, ps.equals(ps), the result will be false. I verified
> this by setting a breakpoint in the SqlExecutor class and ran this
> evaluation which resulted in false.
> I don't have a solution to this unfortunately. I first thought a simple
> comparison of the parameter object being an instanceof PreparedStatementLogProxy,
> but that also returns false, as does PreparedStatementLogProxy.*class*.isAssignableFrom(params[0].getClass()).
> My problem is that the Statements are always being close when they should
> not be and this is resulting in errors being raised from the JDBC layer
> because the Statement is being closed more than once. This is because when
> SqlMapSessionImpl.close() is called the delegate, SqlMapExecutorDelegate
> pushSession method is called. In here session.reset() is called which
> closes any PreparedStatements that it contains. Effectively closing the
> PreparedStatement twice.
> Should I open an JIRA on this?
> Chris Mathrusse
> christopher.mathrusse@sybase.com
> (925) 236-5553

View raw message