You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Katilie, John" <Jo...@softwareagusa.com> on 2008/06/18 01:51:07 UTC

Connection Pooling and Teradata 

I'm not sure if this is the right place to post this question but I've
seen through the years that there are a lot of knowledgeable people
reading and responding. 

 

1st. I'm running Tomcat 6.0.14 under Windows XP with Java 1.5.09. 

 

2nd: My problem is not getting something working its trying to
understand what is happening to see if I can get it to work faster.

 

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

 

<!-- Sample Database DataSource Configuration  for Teradata
-->

    <Resource

      name="jdbc/teradata1"

      factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"

      url="jdbc:teradata://adqaxp01/LOG=DEBUG,DATABASE=Mydb"

      driverClassName="com.ncr.teradata.TeraDriver"

      username="****"

      password="****"

      validationQuery="Select 1"

      type="javax.sql.DataSource"

      maxIdle="2"

      maxWait="5000"

      maxActive="4"

  />

 

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

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

 

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?

 

Any and all feedback is appreciated.

 

Thanks, John Katilie

Re: Connection Pooling and Teradata

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

Katilie, John wrote:
| Chris, 1st I tried adding log4j.properies [...]

Take a look at all the messages running around the list this week about
logging. Apparently, it's rocket science.

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

iEYEARECAAYFAkhZXjUACgkQ9CaO5/Lv0PCCWgCfYUA9v2UTGkK6YRh3S1oHjq27
PR8AnRH4JBaa8212BREUniVAznVJb25d
=glYI
-----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: Connection Pooling and Teradata

Posted by David Smith <dn...@cornell.edu>.
There real unfortunate part with regard to log4j is the actual manual 
has to be purchased.   The site docs are horribly lacking.

Having said that ... I suspect because the DBCP pool is created by 
tomcat in tomcat's internal code, it has a different log factory 
instance and as a result, a different config and different file to 
output to.  Altering tomcat's conf/logging.properties will probably be 
more effective in getting debug output for tomcat's DBCP.

--David

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>
> Katilie, John wrote:
> | Chris, 1st I tried adding log4j.properies [...]
>
> I use log4j, and have it correctly configured to use log4j in my
> application, so I added:
>
> log4j.category.org.apache.tomcat.dbcp=ALL
>
> to my log4j.properties file, and that does not seem to have added
> anything to my logs. Perhaps it's because DBCP is loaded by TC before my
> webapp, so it's using a differently-configured logger.
>
> I'll keep looking.
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhZXyAACgkQ9CaO5/Lv0PCmZACfba4TzsEq5LPCtwXirWZmJNJz
> nCYAoMIL24Rrb4inEGuCT41ynUC/7t83
> =upFT
> -----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
>


-- 
David Smith
Network Operations Supervisor
Department of Entomology
Cornell University
2132 Comstock Hall
Ithaca, NY 14853
Phone: (607) 255-9571
Fax: (607) 255-0940


---------------------------------------------------------------------
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: Connection Pooling and Teradata

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: Connection Pooling and Teradata
>
> Perhaps it's because DBCP is loaded by TC before my
> webapp, so it's using a differently-configured logger.

I believe that's the case - different classloader, different logger.  The DBCP classes should be handled by Tomcat's classloader, not your webapp's.  If you're still using JULI for TC logging, try adding the equivalent to conf/logging.properties.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
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: Connection Pooling and Teradata

Posted by "Katilie, John" <Jo...@softwareagusa.com>.
Thanks, for the effort. It's interesting that when I moved my log4j jar
file from my apps directory into tomcat/lib and added the log4j parm in
my apps log4j.properties file I got tons of logging messages but none
from dbcp..

log4j.logger.org.apache=ALL, DBCPCONSOLEAppender

Thanks, jfk

-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: Wednesday, June 18, 2008 4:05 PM
To: Tomcat Users List
Subject: Re: Connection Pooling and Teradata

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

John,

Christopher Schultz wrote:
| I use log4j, and have it correctly configured to use log4j in my
| application, so I added:
|
| log4j.category.org.apache.tomcat.dbcp=ALL

I followed the instructions on this page
(http://tomcat.apache.org/tomcat-5.5-doc/logging.html) to set up Tomcat
to use log4j. I set the following log4j.properties:

log4j.rootLogger=INFO,R
log4j.appender.R=org.apache.log4j.FileAppender
log4j.appender.R.File=/tmp/tomcat.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

log4j.category.org.apache.tomcat.dbcp=ALL

... and got no useful output from DBCP in /tmp/tomcat.log (which was
created and did have output from other components).

A commons-user post from a few years ago seems to indicate that DBCP
does not do any logging. A cursory look at the source myself confirms
this assertion. :(

That would have been easier to check than re-configuring my Tomcat ;)

Anyhow, you could always browse the code to check for additional
statements issued by DBCP. Other than the "validation query" and
possibly a COMMIT issued when returning an autocommit=false connection
back to an autocommit=true pool (because setting autocommit=true on an
autocommit=false connection causes a COMMIT to occur), there should be
no query overhead added by DBCP.

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

iEYEARECAAYFAkhZan8ACgkQ9CaO5/Lv0PBHigCcCnlWOBhRwU6fwFeKHGeg43+2
HL8AoMGNUUoycYbmPE3T78LD89Ggl7iF
=ZhdY
-----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


---------------------------------------------------------------------
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: Connection Pooling and Teradata

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

Christopher Schultz wrote:
| I use log4j, and have it correctly configured to use log4j in my
| application, so I added:
|
| log4j.category.org.apache.tomcat.dbcp=ALL

I followed the instructions on this page
(http://tomcat.apache.org/tomcat-5.5-doc/logging.html) to set up Tomcat
to use log4j. I set the following log4j.properties:

log4j.rootLogger=INFO,R
log4j.appender.R=org.apache.log4j.FileAppender
log4j.appender.R.File=/tmp/tomcat.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

log4j.category.org.apache.tomcat.dbcp=ALL

... and got no useful output from DBCP in /tmp/tomcat.log (which was
created and did have output from other components).

A commons-user post from a few years ago seems to indicate that DBCP
does not do any logging. A cursory look at the source myself confirms
this assertion. :(

That would have been easier to check than re-configuring my Tomcat ;)

Anyhow, you could always browse the code to check for additional
statements issued by DBCP. Other than the "validation query" and
possibly a COMMIT issued when returning an autocommit=false connection
back to an autocommit=true pool (because setting autocommit=true on an
autocommit=false connection causes a COMMIT to occur), there should be
no query overhead added by DBCP.

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

iEYEARECAAYFAkhZan8ACgkQ9CaO5/Lv0PBHigCcCnlWOBhRwU6fwFeKHGeg43+2
HL8AoMGNUUoycYbmPE3T78LD89Ggl7iF
=ZhdY
-----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: Connection Pooling and Teradata

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

Katilie, John wrote:
| Chris, 1st I tried adding log4j.properies [...]

I use log4j, and have it correctly configured to use log4j in my
application, so I added:

log4j.category.org.apache.tomcat.dbcp=ALL

to my log4j.properties file, and that does not seem to have added
anything to my logs. Perhaps it's because DBCP is loaded by TC before my
webapp, so it's using a differently-configured logger.

I'll keep looking.

- -chris

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

iEYEARECAAYFAkhZXyAACgkQ9CaO5/Lv0PCmZACfba4TzsEq5LPCtwXirWZmJNJz
nCYAoMIL24Rrb4inEGuCT41ynUC/7t83
=upFT
-----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: Connection Pooling and Teradata

Posted by "Katilie, John" <Jo...@softwareagusa.com>.
Chris, 1st I tried adding log4j.properies in my webapp log4j.properties
for the class org.apache.tomcat.dbcp, then after reading some doc I
added:

org.apache.naming.level=FINE
org.apache.tomcat.dbcp.level=FINE

in the tomcat/conf/logging.properties file. That seemed to produce
nothing..

King Regards, John Katilie. 

-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: Wednesday, June 18, 2008 1:16 PM
To: Tomcat Users List
Subject: Re: Connection Pooling and Teradata

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

John,

Katilie, John wrote:
| Chris, Thanks for your reply. I'll do some more testing. May i ask a
| dumb question? How did you turn on your tracing to get:

I used the tracing provided by my JDBC driver (Connector/J), so you
won't have this exact option.

| I tried doing a number of things but could never get any trace output
| from org.apache.tomcat.dbcp.*.

What did you try?

I have never tried to get dbcp to dump logging information, but they
probably use commons-logging, so you could probably configure logging
for those classes at the TRACE level and see what comes out.

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

iEYEARECAAYFAkhZQrcACgkQ9CaO5/Lv0PC+sgCfRuWSkXAj8GGO3qyUE9u2/Kt+
ZjQAoI13stQm6sJWwOEVXphVezWyatog
=Nk1A
-----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


---------------------------------------------------------------------
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: Connection Pooling and Teradata

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

Katilie, John wrote:
| Chris, Thanks for your reply. I'll do some more testing. May i ask a
| dumb question? How did you turn on your tracing to get:

I used the tracing provided by my JDBC driver (Connector/J), so you
won't have this exact option.

| I tried doing a number of things but could never get any trace output
| from org.apache.tomcat.dbcp.*.

What did you try?

I have never tried to get dbcp to dump logging information, but they
probably use commons-logging, so you could probably configure logging
for those classes at the TRACE level and see what comes out.

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

iEYEARECAAYFAkhZQrcACgkQ9CaO5/Lv0PC+sgCfRuWSkXAj8GGO3qyUE9u2/Kt+
ZjQAoI13stQm6sJWwOEVXphVezWyatog
=Nk1A
-----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: Connection Pooling and Teradata

Posted by "Katilie, John" <Jo...@softwareagusa.com>.
Chris, Thanks for your reply. I'll do some more testing. May i ask a
dumb question? How did you turn on your tracing to get:

Wed Jun 18 09:39:20 EDT 2008 INFO: Profiler Event: [QUERY]      at
org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingS
tatement.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(DelegatingS
tatement.java:208)
duration: 0 ms, connection-id: 1236, statement-id: 41, resultset-id: 39
...

I tried doing a number of things but could never get any trace output
from org.apache.tomcat.dbcp.*. That's when I ended up turning on the
Teradata driver tracing by adding LOG=DEBUG in the url string.

Thanks again, John Katilie
 
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: Wednesday, June 18, 2008 9:46 AM
To: Tomcat Users List
Subject: Re: Connection Pooling and Teradata

-----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(DelegatingS
tatement.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(DelegatingS
tatement.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(DelegatingS
tatement.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(DelegatingS
tatement.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


---------------------------------------------------------------------
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: Connection Pooling and Teradata

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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