Re: stmt.getConnection() != Connection used to create the statement

[Alexander Rupsch]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: stmt.getConnection() != Connection used to create the statement

[Alexander Rupsch]

 I have the same problem while using dbcp with OC4J. Are you using it ?
No, dbcp is directly integrated in my application. It's a problem of dbcp...


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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

stmt.getConnection() != Connection used to create the statement

[Alexander Rupsch]

Hi,

I'm not an expert in implementing connection pools or jdbc itself. But
shouldn't the following code work?

Connection con = pool.getConnection()
PreparedStatement ps = con.prepareStatement()

con.equals(ps.getConnection) // returns false!

Ok, I don't need it to be equal, but the following also does not work:

ps.getConnection().close()
con.isClosed() // is false!!!

That means, if I have a Statment and want to close its connection, I
have to remember the conncetion by myself. Is that the requested
behavior? Because of this my pool was running over.

The java.sql API says that Statment.getConnection() has to be the
connection which created the statement.

regards.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]