tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Connection Pooling and Teradata
Date Wed, 18 Jun 2008 13:46:13 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Katilie,

Katilie, John wrote:
| Basically, I have a web application that communicates with Teradata
| under Tomcat using a DBCP pooled connection. In my context.xml file I
| have:

[snip]

|       validationQuery="Select 1"

[snip]

| Via JNDI we get the Resource object, get a connection, create a
| statement, issue the statement, close the statement and then close the
| connection. Everything works just fine. But looking at a Teradata
| command log and then turning on LOG=DEBUG on the URL I see 2 things.
|
| 1st. Everytime we get a connection I see a "Select 1" followed by a
| BT/Rollback being issued and

The "SELECT 1" is because of your validation query in the <Resource>
configuration. I'm not sure why a ROLLBACK is being issued -- perhaps
your driver does this automatically or something?

| 2nd: Everytime we close the connection I see an "Abort" followed by
| multiple ET/Commit's being issued

Again, this might be your driver. You should write yourself a little
test class to just issue a simple query, and turn on DEBUG mode on your
driver, to see what happens when connection pooling is not used.

Are you using transactions?

I'm using MySQL 5.0.x with Connector/J 5.0.8 on TC 5.5.23 and Java
1.5.0_13 and my JDBC driver reports the following queries when executing
"SELECT 'foo'" without a transaction or anything like that. Auto-commit
is set to "true".

Wed Jun 18 09:39:20 EDT 2008 INFO: Profiler Event: [QUERY]      at
org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
duration: 0 ms, connection-id: 1236, statement-id: 41, resultset-id: 39,
message: SELECT 1
Wed Jun 18 09:39:20 EDT 2008 INFO: Profiler Event: [FETCH]      at
org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
duration: 0 ms, connection-id: 1236, statement-id: 41, resultset-id: 39
Wed Jun 18 09:39:20 EDT 2008 INFO: Profiler Event: [QUERY]      at
org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
duration: 1 ms, connection-id: 1236, statement-id: 42, resultset-id: 40,
message: SELECT 'foo'
Wed Jun 18 09:39:20 EDT 2008 INFO: Profiler Event: [FETCH]      at
org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
duration: 0 ms, connection-id: 1236, statement-id: 42, resultset-id: 40

Through all that, the only queries executed are:

SELECT 1      (the validation query)
SELECT 'foo'  (the query I wanted to run)

| I've seen similar things with other DB's and am now wondering if I have
| a problem or is this the way it is designed to work?
|
| Using connection pooling is it normal to issue the above commands when a
| connection is obtained and closed? Is there something I can do to say
| don't do it? Is it an Application error, Tomcat error or JDBC driver
| error?

I would take some of your code out of your application and run it in a
test bed -- that will tell you how much of the overhead is coming from
your own application and how much is being added by DBCP. There's always
the possibility that your driver itself is adding these COMMIT/ROLLBACK
queries.

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

iEYEARECAAYFAkhZEaUACgkQ9CaO5/Lv0PCjHACaAugA+Vnyv/6SV2bZch7JVTQ8
rPgAoIEcl71fbOeNO48FmZx65wizVJnD
=aI2l
-----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


Mime
View raw message