[Mondrian] SqlStatement not closed
mkambol at gmail.com
Tue Sep 29 17:34:21 EDT 2009
Thanks Julian. I hadn't noticed that SqlStatement was calling close on
SQLException. We have a custom JDBC driver that in this case wasn't
throwing a SQLException (although it probably should have been).
Should the catch block in SqlStatement be broader than just SQLException?
On Tue, Sep 29, 2009 at 4:52 PM, Julian Hyde <jhyde at pentaho.com> wrote:
> By design, you do not need to call close if executeQuery encounters an
> exception. SqlStatement.execute should do it automatically. The code assumes
> that this is the case. Is this not happening? Maybe you're getting a
> throwable which is not a SQLException.
> If executeQuery succeeds, you do need to call close.
> By the way, http://jira.pentaho.com/browse/MONDRIAN-623 may be the same
> issue as you are seeing.
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Matt Campbell
> *Sent:* Tuesday, September 29, 2009 12:58 PM
> *To:* Mondrian developer mailing list
> *Subject:* [Mondrian] SqlStatement not closed
> There are several places in the code base where RolapUtil.executeQuery() is
> called outside of a try/catch/finally. Since the statement .close() method
> is typically called in the finally, this has the potential to cause
> statements to be left open if an exception is thrown during the
> We recently experienced this when we had a series of SQL queries fail with
> an exception. Each of those failures left the statement open, which meant
> that the Semaphore never incremented its query count. I think if the query
> fails it should still close the statement.
> Can/should we move the executeQuery() to within the try block in the
> handful of places where it is invoked?
> Mondrian mailing list
> Mondrian at pentaho.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mondrian