Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Cecil Westerhof <Cecil@decebal.nl>
Newsgroups: comp.lang.java.programmer
Subject: Re: Not closing a SQL(ite3) connection
Date: Sat, 12 Aug 2017 16:37:02 +0200
Organization: Decebal Computing
Lines: 48
Message-ID: <87378wzwc1.fsf@munus.decebal.nl>
References: <87a839um2q.fsf@munus.decebal.nl> <omg0la$1qe3$1@gioia.aioe.org> <874lte1pdj.fsf@munus.decebal.nl> <omli1h$jt7$1@gioia.aioe.org> <slrnootj2q.o2q.avl@logic.at> <87bmnlyrx7.fsf@munus.decebal.nl> <slrnoou0q9.o2q.avl@logic.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="a1c8c080b2cb6129343ef73ef98e693f"; logging-data="3443"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19PWQVxOZrWtN/yR/sR4/jUN9bOtcMg+X0="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:ehiqgelwNZrhU0+RDqbsn2CFX2Y= sha1:qRkRhy3wnSmachzVeklZ98nxIJY=
X-Homepage: http://www.decebal.nl/
Xref: csiph.com comp.lang.java.programmer:37148

Andreas Leitgeb <avl@logic.at> writes:

>> My real code has become:
>>         try {
>>             Statement stmt = resultSet.getStatement();
>>             resultSet.close();
>>             closedResultSet = true;
>>             stmt.close();
>
> That's a meaning of "real code", that I'd consider rather odd ;-)
> It's probably more like: the new "real" test code ...

Nope, I think this is real code. But if there is an error, I do not
mind to be told that.

I have now a class SQLResultSet. I now only have to get an instance of
this class instead of an instance of Statement and ResultSet. When the
instance of SQLResultSet is closed, its ResultSet needs to be closed
and its implicit Statement. Otherwise there is a leak.


> If the resultSet is already closed, then retrieving the Statement 
> from it might already fail (and the result might make you think that
> closing the resultset threw, when it might just as well have been
> already the .getStatement(); - both before setting the boolean.
> Maybe my other followup might still be in principle relevant.

That is a good point: what to do if close is called more as once. You
keep me busy. ;-)

I already have a different throw for when the retrieving of Statement
goes wrong. See my other reply.


> If instead the resultSet was still open at time of calling your code,
> then there shouldn't really be any exception thrown at all.

It should not, but when making a library you have to cover all your
bases.


I plan in making it more general also. I initially made it for
SQLite3, but it will not hurt to let it work with ‘all’ databases.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof