-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elli,
On 10/28/2009 12:21 AM, Elli Albek wrote:
In terms of listeners, I saw that Tomcat executes requests while in
the closing process.
That's a problem. What kind of listener are you using?
My understanding was that:
1. Tomcat does not
Hi,
From what I can remember, which has been a long time ago, requests are
being handled by servlets after the shutdown process has started and
the pool was closed. I would imagine that this is a violation of the
spec as well, but I am not sure. You would imagine that JNDI resources
should be
Elli Albek wrote:
2. If your JDBC driver supports caching of prepared statements and
metadata, do it in the driver and disable this in DBCP. IMO DBCP does
a poor job at best in caching. We use mysql and its JDBC driver is
doing an excellent job.
It didn't occur to me that that was available.
3.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elli,
On 10/26/2009 9:01 PM, Elli Albek wrote:
2. If your JDBC driver supports caching of prepared statements and
metadata, do it in the driver and disable this in DBCP. IMO DBCP
does a poor job at best in caching. We use mysql and its JDBC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elli,
On 10/26/2009 10:59 PM, Elli Albek wrote:
To disable caching in DBCP, use configuration option:
poolPreparedStatements=false
Note that this is the default. Presumably, if you don't know if your
prepared statements are being cached, then they
Thanks for your replies. I agree that Tomcat should be responsible for
all objects that are configured in Tomcat, and the web app should be
responsible for objects that are created by the webapp. Currently it
does not happen properly in tomcat. This is not related to DBCP code,
it is all Tomcat
Christopher Schultz wrote:
When you've played with it for a bit, tell us how things turned out.
It's looking like optimal is caching about 40 PreparedStatement objects.
However, I should qualify that noting that it's with our application and
specifically with our little pummeling benchmark,
Bill Davidson wrote:
Christopher Schultz wrote:
When you've played with it for a bit, tell us how things turned out.
It's looking like optimal is caching about 40 PreparedStatement objects.
However, I should qualify that noting that it's with our application and
specifically with our little
Hi,
I did not follow this thread form the beginning, but I can provide a
few tips about using connection pools in tomcat.
1. DBCP has quite a few problems in the area of scalability. We have
our own modified version of the source that makes it more concurrent,
and I believe some of those changes
mggood work
From: e...@sustainlane.com
To: users@tomcat.apache.org
Hi,
I did not follow this thread form the beginning, but I can provide a
few tips about using connection pools in tomcat.
1. DBCP has quite a few problems in the area of scalability. We have
our own modified version of
Hi,
More information about tomcat shutdown and object swapping probably belongs
in the development list. It is quite a bit of work to extend DBCP and write
extensions to tomcat, and at the end of the day most of those problems I
would consider as bugs. DBCP specifically cannot be easily extended,
I already got a response to the ehancement request.
Apparently the documentation will be changed to this:
Make sure your connection has some resources left for the other
statements. Pooling PreparedStatements may keep their cursors open in
the database, causing a connection to run out
Christopher Schultz wrote:
I see you've cross-posted to commons-user. That's good, but you probably
want to file an actually bug report / enhancement request for the
documentation.
Filed. Key: DBCP-301
-
To unsubscribe,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 10/16/2009 5:36 PM, Bill Davidson wrote:
Bill Davidson wrote:
Could maxOpenPreparedStatements possibly fix this?
Apparently it does.
Glad to get the bottom of this problem, though I'm not entirely sure
where it leaves you.
The DBCP
Christopher Schultz wrote:
I'm curious about the usefulness of caching prepared statements in
general, though. What is the default maxOpenPreparedStatements setting
and what did you set it to in order to get it to work out well for you?
The default is unlimited, which is the problem. I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 10/19/2009 3:14 PM, Bill Davidson wrote:
Christopher Schultz wrote:
I'm curious about the usefulness of caching prepared statements in
general, though. What is the default maxOpenPreparedStatements setting
and what did you set it to in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
(I've decided to stop cross-posting to commons-user. If you want to
forward come of my comments, you are welcome to do so).
On 10/15/2009 5:07 PM, Bill Davidson wrote:
I'm a little confused about auto-commit. I don't want my transactions
Christopher Schultz wrote:
Uh, oh. Are you doing something like this:
Possibly. I didn't write that code.
If you're doing that, then you're probably making a big mistake. Are you
storing connections in sessions or anything like that? Yuk.
For certain transactional operations, I think it is.
Just thinking about this some more
So apparently, when I was using poolPreparedStatements=true, and
I did conn.prepareStatement(SomeSQLString), I was getting back a
Statement object created by DBCP to be pooled. When I called close()
on that statement, it did not really close(), which was
Bill Davidson wrote:
Could maxOpenPreparedStatements possibly fix this?
Apparently it does.
The DBCP config docs need a better warning on poolPreparedStatements:
*NOTE* - Make sure your connection has some resources left for the
other statements.
just doesn't quite cut it. Something more
Christopher Schultz wrote:
Is it possible that your server just doesn't want to allocate 245 * 4
cursors, and that you are just hitting that barrier?
cursor != connection
Oracle is set up to allow up to 300 cursors per session (connection).
I could up that limit, but it probably won't fix the
Martin Gainty wrote:
are you running as a Transaction?
In some cases, but a lot of these lingering cursors are on very simple
queries, with no insert/update/delete involved. As I said before,
I'm finding lingering cursors on things as simple as SELECT * FROM
some_table WHERE id = ?.
That does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 10/15/2009 2:15 PM, Bill Davidson wrote:
Christopher Schultz wrote:
Is it possible that your server just doesn't want to allocate 245 * 4
cursors, and that you are just hitting that barrier?
cursor != connection
Right... but presumably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 10/15/2009 2:24 PM, Bill Davidson wrote:
That does make me wonder though if there are Connection's getting sent
back to the pool that had a pending transaction without a commit/rollback
and if that could be making any cursors on that
On Thu, Oct 15, 2009 at 1:46 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
You could also ask on some Java-oriented Oracle forums.
Oracle has a user community called Mix -- https://mix.oracle.com/ --
where you could post your issue (requires registration but otherwise
free).
/*
Christopher Schultz wrote:
Probably not. DBCP calls setAutoCommit(true) by default in order to
reset the connection as it goes back into the pool. Any pending
transaction is committed (!) when that happens, so there shouldn't be
any in-progress transactions lingering around.
If you set
Redhat 5.2 Server
Java: Sun JDK 1.6.0_16 (64-bit)
Tomcat 6.0.20 (and whichever version of DBCP that includes)
Oracle 10g (10.2.0.3)
JDBC: ojdbc14.jar
I've been trying to convert an old J2EE application to use DBCP connection
pools from an old custom connection pool class (not a DataSource
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 10/14/2009 2:17 PM, Bill Davidson wrote:
Redhat 5.2 Server
Wow.
I've been trying to convert an old J2EE application to use DBCP connection
pools from an old custom connection pool class (not a DataSource
interface).
I've moved a
Christopher Schultz wrote:
On 10/14/2009 2:17 PM, Bill Davidson wrote:
Redhat 5.2 Server
Wow.
Maybe I should have said RHEL 5.2. 5.3 would be the current
version, so it's actually not that old. RedHat's starting over with
the numbers does get confusing.
This config looks fine, though the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 10/14/2009 5:05 PM, Bill Davidson wrote:
Usually, we don't need that many [connections], but sometimes, we get hit
really hard
with a lot of traffic and do need that many. BTW, this is load balanced
across 4 servers that can each do
sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Wed, 14 Oct 2009 21:22:35 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
CC: u...@commons.apache.org
Subject: Re: DBCP woes (running out of cursors).
-BEGIN PGP
31 matches
Mail list logo
