Martin Cooper wrote:
What do you have in mind with regard to Digester-based
configuration? I'd be willing to take a crack at doing
this if you could give me some pointers on what you'd like
to see. Bear in mind that I'm not exactly a JOCL expert. ;-)
Recall that an instance of DBCP glues
On 3/6/02 2:53 PM, John McNally [EMAIL PROTECTED] wrote:
The code in sandbox/jdbc2pool uses the commons pool and DBCP's
PreparedStatement pool while attempting to implement the jdbc2
specification. Geir and anyone else at jakarta who wants to work on a
connection pool, why not join me in
- Original Message -
From: Geir Magnusson Jr. [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, March 06, 2002 12:16 PM
Subject: Re: commons dbcp or pool problems
On 3/6/02 2:53 PM, John McNally [EMAIL PROTECTED] wrote:
The code in sandbox
- Original Message -
From: Waldhoff, Rodney [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List ' [EMAIL PROTECTED]
Sent: Wednesday, March 06, 2002 4:27 AM
Subject: RE: commons dbcp or pool problems
What is the status of commons dbcp?
Is this considered done
and production
So in the event anyone is interested, the Poolman maintainer has
retired.
I no longer have time to maintain the PoolMan
JDBC driver and resource pooling and caching
utility, and am now seeking a qualified,
comitted software engineer to assume control
over its future. If interested, please send
What is the status of commons dbcp?
Apart from what look like minor edits from Craig, it's been 10 months
(according to CVS) since any major work has been done. Is this
considered done and production quality or it still in beta (or less?)
I noticed that it's part of the Struts nightly build
On Tue, 26 Feb 2002, Juozas Baliuka wrote:
Date: Tue, 26 Feb 2002 19:12:36 +0100
From: Juozas Baliuka [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: commons dbcp
PROTECTED]
Subject: RE: commons dbcp or pool problems
On Tue, 26 Feb 2002, Aaron Smuts wrote:
Does the pool you are working on work with JDK1.4 and 1.3?
This is a nasty issue, due to the changes in java.sql.Connection in
1.4.
Basically, it's not possible to write a single
This isn't necessary.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 26, 2002 12:41 PM
To: Jakarta Commons Developers List
Cc: [EMAIL PROTECTED]
Subject: Re: commons dbcp or pool problems
On Tue, 26 Feb 2002, Juozas Baliuka
skip
Craig
I see only one possible solution : to have two tagets in ant script, one
for
jdk1.3 and for 1.4,
conditional compling is not very nice solution, but I see no choises.
Doing the conditional compilation part is pretty straightforward. We'll
also want to make the DBCP
:[EMAIL PROTECTED]]
Sent: Monday, February 25, 2002 7:02 PM
To: Jakarta Commons Developers List
Subject: Re: commons dbcp or pool problems
Why not just create more connections when the pool is exhausted and
then
log
a warning message, so the bug can be tracked down later without
breaking
Actually, now that I'm more awake, I think the idea of a thread timing
out borrowed connections is a bad thing. -- It adds more code to DBCP, and
adds the overhead of an extra thread. To top that off, its only purpose in
life is to work around code problems, rather than fixing them.
With
Hi,
You can implement this without any extra thread. Pooling doesn't need
threads, but amost all
pool and cashe implementations use extra threads( it does nothing
meaningful).
Idea to use timeout is not very good, only crapy application needs this, I
think it is
good to have it for debug, but
Comments intermixed below.
Juozas Baliuka wrote:
Hi,
You can implement this without any extra thread. Pooling doesn't need
threads, but amost all
pool and cashe implementations use extra threads( it does nothing
meaningful).
Idea to use timeout is not very good, only crapy application
But in a production environment where I host the applications, not
write
them, I don't want to be called at 2PM on a Sunday to reboot the app
server
if a customer's application stops working because their bad code
exhausted
their db connection pool.
I really think this feature is
At 2/23/2002 01:25 PM -0600, Rodney Waldhoff wrote:
James House wrote:
A few months back I made my own hacks to
DBCP in order to have it find places in
our code that didn't free up DB resources
properly.
snip
If anyone's interested, I could try
digging it up, and posting it.
Hi,
Worse than using sql within a JSP, the customer turned almost their
entire web site into a bunch of JSP pages to dynamically generate
the content from a db. But they only change the db 5-6 times a day.
So their pages generate all this load and are open to all kinds of
potential
At 2/23/2002 01:25 PM -0600, Rodney Waldhoff wrote:
A few months back I made my own hacks to
DBCP in order to have it find places in
our code that didn't free up DB resources
properly.
I was able to generate class names and
line-numbers (stack trace) for every place
in the code
I like this. There is another option which could be added.
clientTimeout
It the pool exhausts its connections, it will review the list
of connections in use, the connection which exceeds the clientTimeout
by the most gets recycled. If all the Statements are tracked,
they can be closed (which
Actually, I had it working that way for a while too, but had complaints
(in-house) about the extra thread... But I'd be happy to throw it in.
I guess the question is: Should this be in the standard DBCP stuff (with
an on-off switch) or as separate classes only for use during debugging?
On Fri, 22 Feb 2002, Glenn Nielsen wrote:
I have been using Tomcat 4.1-dev and its new DBCP DataSource Factory
which uses commons-dbcp, which then uses other commons components
like commons-pool.
Everything works fine, then all of a sudden GenericPool can no longer
get a db connection from
As you probably already know, the NoSuchElementException is telling you the
pool has been exhausted (and the detail message suggests you've got the
pool configured to block for some finite amount of time before giving up).
The most probable causes, in my experience:
1. A peak in connection
Juozas wrote:
It is very dificult to find pooling
related bugs in application. May be
it has meaning to implement something
like DebugPool to help find problems
in users code. I can think about this,
if this idea is interesting.
In the pool/dbcp implementation from which
Juozas wrote:
It is very dificult to find pooling
related bugs in application. May be
it has meaning to implement something
like DebugPool to help find problems
in users code. I can think about this,
if this idea is interesting.
In the pool/dbcp implementation from which
I have reviewed the customers JSP pages and found one page
where they were not wrapping their use of a db connection within a
try {} block. I have informed them how to fix it.
But this one page does not explain running out of connections in a pool
with a max of 75 connections. In the
Hi,
I have reviewed the customers JSP pages and found one page
where they were not wrapping their use of a db connection within a
try {} block. I have informed them how to fix it.
But this one page does not explain running out of connections in a pool
with a max of 75 connections. In the
At 2/22/2002 08:47 PM +0100, Juozas Baliuka wrote:
It is very dificult to find pooling related bugs in application.
May be it has meaning to implement something like DebugPool to help find
problems
in users code.
I can think about this, if this idea is interesting.
A few months back I made my
Waldhoff, Rodney wrote:
As you probably already know, the NoSuchElementException is telling you the
pool has been exhausted (and the detail message suggests you've got the
pool configured to block for some finite amount of time before giving up).
The most probable causes, in my experience:
Glenn Nielsen wrote:
Waldhoff, Rodney wrote:
As you probably already know, the NoSuchElementException is telling you the
pool has been exhausted (and the detail message suggests you've got the
pool configured to block for some finite amount of time before giving up).
The most
Gerhard Froehlich wrote:
Hi,
I have reviewed the customers JSP pages and found one page
where they were not wrapping their use of a db connection within a
try {} block. I have informed them how to fix it.
But this one page does not explain running out of connections in a pool
with a
Worse than using sql within a JSP, the customer turned almost their
entire web site into a bunch of JSP pages to dynamically generate
the content from a db. But they only change the db 5-6 times a day.
So their pages generate all this load and are open to all kinds of
potential failures for
--- Glenn Nielsen [EMAIL PROTECTED] wrote:
Worse than using sql within a JSP, the customer turned almost their
entire web site into a bunch of JSP pages to dynamically generate
the content from a db. But they only change the db 5-6 times a day.
In the Commons-Pool is a taglib for caching
Hi,
Worse than using sql within a JSP, the customer turned almost their
entire web site into a bunch of JSP pages to dynamically generate
the content from a db. But they only change the db 5-6 times a day.
So their pages generate all this load and are open to all kinds of
potential
Thanks for the suggestion.
The issue of caching pages was discussed weeks ago with the customer.
But of course the customer doesn't have time to make changes now,
it has to go into production. They have something that works.
If they eventually have time to redesign the application I will
34 matches
Mail list logo
