Re: [OT] Connection Pool and Connections

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lightbulb,

(I marked this as off-topic since it's really a JDBC/DBCP issue, not a
Tomcat one. I'm still happy to answer.)

lightbulb432 wrote:
> Is it possible that myStatement1 and myStatement2 would be run using
> different physical database connections, or are they absolutely guaranteed
> to be executed using the same connection?

They are guaranteed to act like they are executing through the same
connection, even if they aren't (not sure how loose the spec is). You
should check the JDBC specification to make sure, but I would imagine
that splitting statements across connections would be more trouble than
it's worth... I doubt very seriously that anyone would ever want to do this.

> Or is connection pooling only for not actually closing the physical database
> connection on myConnection.close(), instead returning it to the connection
> pool?

Pretty much. The connection pool simply ... pools connections. Once you
have a connection, you can do whatever you want (including never
returning it to the pool, which isn't a good idea, of course).

> A different way of asking this is does connection pooling pool connections
> within an application connection (myDataSource.getConnection() and
> myConnection.close()), or between application connections?

Well... when you call myDataSource.getConnection, it gives you a
connection from the pool. When you call connection.close(), it returns
the connection to the pool. Technically, while you have control of the
connection, it's not pooled... it's "out of the pool with the intent to
be returned soon".

> If this question doesn't make sense, I can clarify. Thanks a lot.

I hope my answer makes sense ;)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGYH4s9CaO5/Lv0PARAihvAJwKgt3EccemfZ9AhtT6JI0EKAjF7wCgnu8g
v0pYh6pxJPAZTt2lEGZXjJ4=
=AGDl
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Connection Pool and Connections

[Pid <p...@pidster.com>]

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> lightbulb,
> 
> (I marked this as off-topic since it's really a JDBC/DBCP issue, not a
> Tomcat one. I'm still happy to answer.)
> 
> lightbulb432 wrote:
>> Is it possible that myStatement1 and myStatement2 would be run using
>> different physical database connections, or are they absolutely guaranteed
>> to be executed using the same connection?
 >
> They are guaranteed to act like they are executing through the same
> connection, even if they aren't (not sure how loose the spec is). You
> should check the JDBC specification to make sure, but I would imagine
> that splitting statements across connections would be more trouble than
> it's worth... I doubt very seriously that anyone would ever want to do this.
> 
>> Or is connection pooling only for not actually closing the physical database
>> connection on myConnection.close(), instead returning it to the connection
>> pool?
> 
> Pretty much. The connection pool simply ... pools connections. Once you
> have a connection, you can do whatever you want (including never
> returning it to the pool, which isn't a good idea, of course).
> 
>> A different way of asking this is does connection pooling pool connections
>> within an application connection (myDataSource.getConnection() and
>> myConnection.close()), or between application connections?

Also worth noting is that if you can use a PreparedStatement (because 
the instruction is the same and the data is different), then the 
statement/object itself is re-used which further optimises your application.

p

> Well... when you call myDataSource.getConnection, it gives you a
> connection from the pool. When you call connection.close(), it returns
> the connection to the pool. Technically, while you have control of the
> connection, it's not pooled... it's "out of the pool with the intent to
> be returned soon".
> 
>> If this question doesn't make sense, I can clarify. Thanks a lot.
> 
> I hope my answer makes sense ;)
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGYH4s9CaO5/Lv0PARAihvAJwKgt3EccemfZ9AhtT6JI0EKAjF7wCgnu8g
> v0pYh6pxJPAZTt2lEGZXjJ4=
> =AGDl
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
>