Phil Steitz wrote:
Sorry for the slow response. Sounds like you have solved your
problem. I assume you are now getting SQLExceptions when you go
past the maxOpenPreparedStatements limit. If not, there must be
something else going on.
Things are working fine now that I have it limited. No
on, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Sun, 18 Oct 2009 13:10:45 -0400
> From: phil.ste...@gmail.com
> To: user@commons.apache.org
> Subject: Re: DBCP woes (running out of cursors).
>
> Bill Davidson wrote:
> > Bill Davidson w
Bill Davidson wrote:
> 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."
>
> jus
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.
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
-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: us...@tomcat.apache.org
> CC: user@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
Bill Davidson wrote:
> 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
-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
16 matches
Mail list logo
