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 avai
-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 no
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 cod
-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 the
-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 dri
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.
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, w
mg>good 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 vers
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 we
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 l
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, whic
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, e-
-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 t
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 b
-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 DB
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
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
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.
-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
> a
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 auto
On Thu, Oct 15, 2009 at 1:46 PM, Christopher Schultz
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).
/* It's JRuby on Rails but not,
-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 co
-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 presu
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 doe
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
les email peuvent facilement
être 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: D
-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
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 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 co
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 interf
31 matches
Mail list logo
