ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Statements being closed when they shouldn't be
Date Fri, 27 Oct 2006 23:42:32 GMT
Yes - it's new since 2.2.0.  I discovered it in some of my own testing, but
haven't entered it into JIRA yet.  Our JIRA practices are still pretty loose
I'm afraid :(  Go ahead and enter a JIRA for it so it's not forgotten.
Clinton or I will get to it.  Or, if you fix it, then you can attach a patch
to the JIRA ticket.

Jeff Butler




On 10/27/06, Christopher.Mathrusse@sybase.com <
Christopher.Mathrusse@sybase.com> wrote:
>
>  Yes, if I disable logging all together the error does not occur. I'm
> guessing that this is something that you have seen before.
>
>  ------------------------------
> *From:* "Jeff Butler" <jeffgbutler@gmail.com> [mailto:"Jeff Butler" <
> jeffgbutler@gmail.com>]
> *Sent:* Friday, October 27, 2006 12:40 PM
> *To:* user-java@ibatis.apache.org
> *Subject:* Re: Statements being closed when they shouldn't be
>
>
>  Maybe.
>
> Chris - can you verify whether the behavior changes if you disable
> logging?
>
> Also, you can disable caching completely by altering the methods in
> com.ibatis.sqlmap.engine.scope.SessionScope to always return false.
>
> Jeff Butler
>
>
> On 10/27/06, Clinton Begin <clinton.begin@gmail.com> wrote:
> >
> > Yeah, let's open a JIRA issue....
> >
> > JEFF:  Could this be the same problem with the prepared statement
> > caching when logging is enabled?
> >
> > Cheers,
> > Clinton
> >
> > 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
> > >
> > >
> >
> >
>

Mime
View raw message