Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of Alexander.Rupsch@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <431B3B64.4060005@gmx.de>
Date: Sun, 04 Sep 2005 20:22:28 +0200
From: Alexander Rupsch <Alexander.Rupsch@gmx.de>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: stmt.getConnection() != Connection used to create the statement
References: <430259E8.5040003@gmx.de> <43031D13.1080904@c1-fse.de>
 <4303A69D.7010405@gmx.de> <4309BC9F.1000006@c1-fse.de>
In-Reply-To: <4309BC9F.1000006@c1-fse.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Hello Alexander,

> Yes, you have to do it. I can't tell about a specific standardization
> document, but I think it's a best practice of pool implementors to rely
> on users to close connections explicitly. The reason is that you can use
> connections from pools for more than one statement, thus, you have to
> close it in order to allow the pool to determine if that connection can
> be reused.

Well, I know. But if I ask a statement for its creating connection
(stmt.getConnection()) and then then call close on that connection, the
connection won't be closed (at least not the one I used to call
createStatment()). So, what does the close call do in that
constellation?  what is closed/returned to the pool?

> What is your problem with remembering the reference to the connection?

Nothing in common. I have a BaseDAO class which is used as base for my
DAOs. The DAOs are generated. To simplify my generator template there is
a method createPreparedStatement() which is getting a connection an
creates a prepared statement. The method always ask the pool for a
connection. The specific DAO uses a standard cleanup which closes the
statement and the its creating connection. After changing to dbcp as
pool implementation, i run into the problem described above. Apart from
the fact, that the DAO only should to worry about the statement if it
only gets a statement, I wanted to know why pools don't implement
stmt.getConnection() in the way the JDBC-API claims it.


>>I also could take a look in the statement pooling feature and don't even
>>use a connection., but this wouldn't clarify the problem.
> Sorry, I don't get what you mean here .... ?

Statement pooling is a feature of dbcp, but I never used it until know
and I don't know how it works. If statement pooling would do what its
name says, it could be a solution for me. But this wouldn't answer my
question.

regards...

-- 
Alexander Rupsch
http://www.dreinhalb.de

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org