to implement, if we can
not
> > to detect leak to fire event.
> > But sandbox is open for R&D.
> >
> > - Original Message -
> > From: "Danny Angus" <[EMAIL PROTECTED]>
> > To: "Jakarta Commons Developers List" <[EMAIL
ot;Danny Angus" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, July 24, 2003 10:15 AM
> Subject: [DBCP] Event/Listener proposal (was .. RE: [DBCP]
> AbandonedTrace -
> Connection Recovery)
>
>
> >
o detect leak to fire event.
But sandbox is open for R&D.
- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 10:15 AM
Subject: [DBCP] Event/Listener proposa
+1 on a listener model but let's not rule out using the Strategy pattern
as well. They both may come in handy.
David
--- Danny Angus <[EMAIL PROTECTED]> wrote:
> Well I never,
> There's been a lot of talk generated by my innocent proposal of using
> the
> Observer pattern, or in more java-esque
> -Original Message-
> From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
> Sent: 23 July 2003 12:52
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
> Logging is useless in this case,
Such a statement seems ludicrous...
Well I never,
There's been a lot of talk generated by my innocent proposal of using the
Observer pattern, or in more java-esque terms events and listeners to arrive
at a compromise in the Connection Recovery War. I'd like to clarify some
points raised.
In the first place to address the criticism o
#x27;Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 4:16 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
>
> > -Original Message-
> > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]
> > Sent: 23 July 2003 1
#x27;Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 4:16 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
>
> > -Original Message-
> > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]
> > Sent: 23 July 2003 1
ent: Wednesday, July 23, 2003 10:54 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> >
> > Do not use broken code for production, but it must be possible to solve
> > without broken pool.
> >
> What utopia do you live in? I think it would be a close approx
>
> Do not use broken code for production, but it must be possible to solve
> without broken pool.
>
What utopia do you live in? I think it would be a close approximation
to say that every piece of software in production use in the world today
has bugs. And it is not a broken pool that allows t
- Original Message -
From: "John McNally" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 8:54 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> > I get the impression that some of you believe connection cleanup is
>
> Using a weak reference for pooled connections which are in use is a good idea
> and I am all for it.
>
> The only problem is that there is no guarantee when the weak referenced
> db connection pool object will be GC'd. That is highly dependent upon
> how the JVM implements GC. There is no g
> I get the impression that some of you believe connection cleanup is
> difficult. It really is trivial to properly dispose of connections in a
> finally block.
It is not always trivial. Yes, you can have some high level try/finally
block to clean up resources, but you must make sure the code
> That sounds like a better implementation as it is unlikely to timeout
> long running transactions. But implementing an Observer pattern in
> the Connection, Statement, ResultSet implementations would still allow
> such an implementation, right?
Let me please take advantage of this moment of san
>
> The current implementation recover's the abandoned connection based
> on an inactivity timeout. So it has to track the last time the
> connection was used. This more tightly couples it to DBCP.
That sounds like a better implementation as it is unlikely to timeout
long running transactions.
David Graham wrote:
Using a WeakHashMap might be a good solution. Connections are
guaranteed
to be closed when they are garbage collected so if a client doesn't
return
a connection and loses all pointers to it, the pool would lose its
reference to it and the Connection would get gc'd. This is
speed...
Matt
> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: 23 July 2003 15:48
> To: Jakarta Commons Developers List
> Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
>
>
> --- "Hope, Matthew" <[EMAIL PROTECTED]>
> > Using a WeakHashMap might be a good solution. Connections are
> guaranteed
> > to be closed when they are garbage collected so if a client doesn't
> return
> > a connection and loses all pointers to it, the pool would lose its
> > reference to it and the Connection would get gc'd. This is *mu
Juozas Baliuka wrote:
/**
* Get a db connection from the pool.
*
* If removeAbandoned=true, recovers db connections which
* have been idle > removeAbandonedTimeout.
*
* @return Object jdbc Connection
*/
As I remember we have decided to log stack trace, but not to
Is this code released as commons component ?
- Original Message -
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 2:56 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recover
> What happens is that the broken app ends up sucking up resources for
> each concurrent request being made to it which is waiting for the
> db connection timeout. Usually this is set to 5-10 seconds.
> This can suck up alot of resources. Memory, threads, etc.
Web server with limited request/th
John McNally wrote:
[snip]
On the implementation. I have not looked closely at the current
implementation as it is not used by the pool that I added to dbcp and I
was trying to start it as a simple implementation of the latest
specification. But it would seem an implementation of this should ju
Hope, Matthew wrote:
I would disagree on one point. The idea of logging when a connection is
closed due to garbage collection finalization strikes me as a good one
(assuming the pool used is using a weakly referenced mapping otherwise
garbage collection release of resources is going to be a real bu
David Graham wrote:
--- "Laird J. Nelson" <[EMAIL PROTECTED]> wrote:
-Original Message-
From: John McNally [mailto:[EMAIL PROTECTED]
Why is this such a contentious issue?
FWIW, because some users have business experience, and some do not.
Those who do recognize that business *runs* on stop
t;
> > -Original Message-
> > From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
> > Sent: 23 July 2003 11:34
> > To: Jakarta Commons Developers List
> > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> >
> >
> >
> >
> > You
Well I never,
There's been a lot of talk generated by my innocent proposal of using the
Observer pattern, or in more java-esque terms events and listeners to arrive
at a compromise in the Connection Recovery War. I'd like to clarify some
points raised.
In the first place to address the criticism o
e the
constraints you have a problem.
Matt
> -Original Message-
> From: Juozas Baliuka [mailto:[EMAIL PROTECTED]
> Sent: 23 July 2003 11:34
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
>
>
&g
Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 10:50 AM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
a viewpoint I can sympathise with but I don't see how that effects the use
case I outlined below. This is not recovery,
You misunderstand me. http://www.springframework.org/ I have never used this
framework, but I use the same ideas.
> > I did a lot of this kind of bugs myself too and it is very
> > trivial to fix.
> > 1. Set maxConnections to 1 for testing
>
> useful
>
> > 2. Use lazy decorator for connection to
003 09:19
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
>
>
> "Connection Recovery" can not help to solve resouce leak and
> performance
> problems, but It can produce more problems.
> I can not let to brea
> I did a lot of this kind of bugs myself too and it is very
> trivial to fix.
> 1. Set maxConnections to 1 for testing
useful
> 2. Use lazy decorator for connection to throw exeption from "close"
???
> 3. Use "find/replace" to remove all "}finally{ connection.close(); }"
??!?!?!?!
> 4. Store de
ta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 2:34 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
I would disagree on one point. The idea of logging when a connection is
closed due to garbage collection finalization strikes me as a good one
I did a lot of this kind of bugs myself too and it is very trivial to fix.
1. Set maxConnections to 1 for testing
2. Use lazy decorator for connection to throw exeption from "close"
3. Use "find/replace" to remove all "}finally{ connection.close(); }"
4. Store decorator in ThreadLocal and close co
>
> This attitude is not very helpful. I don't see how dbcp supplying the
> ability to configure a connection pool to reclaim connections is that
> big of an issue.
Have you tried to solve problems this way ? Is it tested solution and can be
used for "high quality software" ?
Try to implement an
Juozas Baliuka wrote:
I like innovations, but try to implement and test it at home please.
I am sure there are not so many situations in the real world need this
"feature".
It takes a few minutes to find connection leak and to fix it in any
applications, doe's not it ?
It does not.
I have 2 new
I like innovations, but try to implement and test it at home please.
I am sure there are not so many situations in the real world need this
"feature".
It takes a few minutes to find connection leak and to fix it in any
applications, doe's not it ?
> David Graham wrote:
> > This is absolutely no
David Graham wrote:
This is absolutely not a DBCP code issue; it is a management issue.
Applications that leak resources should have their own separate connection
pool. When they run out of connections, only that app will break and
won't affect any other applications on the server. It will be mu
--- "Laird J. Nelson" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: John McNally [mailto:[EMAIL PROTECTED]
> > Why is this such a contentious issue?
>
> FWIW, because some users have business experience, and some do not.
> Those who do recognize that business *runs* on stopg
> -Original Message-
> From: John McNally [mailto:[EMAIL PROTECTED]
> Why is this such a contentious issue?
FWIW, because some users have business experience, and some do not.
Those who do recognize that business *runs* on stopgap solutions. The
fewer of those stopgap solutions you have t
On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote:
> > I agree that this is an education/policy issue. But sometimes you need
> > a stop gap solution to keep something running while the customer fixes
> > the problem.
> >
> > I would like to see this stop gap solution included with the DBCP releas
On Tue, 2003-07-22 at 10:15, Juozas Baliuka wrote:
>
> http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC
> onnection.html
>
> +1 to implement this interface, but I do not think it can help for broken
> applications.
>
That is an interface to be implemented by a jdbc d
> I agree that this is an education/policy issue. But sometimes you need
> a stop gap solution to keep something running while the customer fixes
> the problem.
>
> I would like to see this stop gap solution included with the DBCP release.
> Along with quality docs on how to properly use a db conn
mmons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 5:38 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
>
> On Tue, 22 Jul 2003, Juozas Baliuka wrote:
>
> > Date: Tue, 22 Jul 2003 14:15:53 +0200
> > From: Juozas Baliuka <[EMAI
David Graham wrote:
--- Serge Knystautas <[EMAIL PROTECTED]> wrote:
David Graham wrote:
IMO, a design that allows users to plugin behaviors, be they
connection
retrieval or otherwise, is the best solution. Then the question
becomes
whether to include a connection retrieval behavior in the DBCP
o: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> >
> >
> > I do not think it is good idea to maintain any kind of public API for
> > "abandoned connections", It is garbage,
> > If ap
On Tue, 22 Jul 2003, Juozas Baliuka wrote:
> Date: Tue, 22 Jul 2003 14:15:53 +0200
> From: Juozas Baliuka <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> S
--- Serge Knystautas <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > IMO, a design that allows users to plugin behaviors, be they
> connection
> > retrieval or otherwise, is the best solution. Then the question
> becomes
> > whether to include a connection retrieval behavior in the DBCP
> rel
- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:18 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
> Juozas,
>
> > I think I will
David Graham wrote:
IMO, a design that allows users to plugin behaviors, be they connection
retrieval or otherwise, is the best solution. Then the question becomes
whether to include a connection retrieval behavior in the DBCP release. I
think that's far outside the scope of DBCP and encourages u
--- Danny Angus <[EMAIL PROTECTED]> wrote:
> Juozas,
>
> > I think I will leave commons and I will spend more my time on SF
> > with forked
> > code, if this kind of vote can win at apache.
> > My input is not a very big, but I will lose any energy to work for
> crap .
>
> I think it is sad that
Juozas,
> I think I will leave commons and I will spend more my time on SF
> with forked
> code, if this kind of vote can win at apache.
> My input is not a very big, but I will lose any energy to work for crap .
I think it is sad that you would rather leave than suggest any alternative.
It hig
Danny Angus wrote:
Serge et al,
Further to my suggestion about using the Observer pattern for event
notification w.r.t. point 4 (below) I forgot to mention that it also has the
benefit of offering a compromise in the pro/anti recovery debate.
Existing contentious code designed to reclaim or test
- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 2:19 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
> Juozas,
>
> > I do not t
22 July 2003 13:16
> To: Jakarta Commons Developers List
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
>
>
> I do not think it is good idea to maintain any kind of public API for
> "abandoned connections", It is garbage,
> If application or server i
Juozas,
> I do not think it is good idea to maintain any kind of public API for
> "abandoned connections", It is garbage,
> If application or server is not broken, it doe's not need workarounds.
It is easy for you to say this, but the fact remains that a number of people
are quite vocal in their
I do not think it is good idea to maintain any kind of public API for
"abandoned connections", It is garbage,
If application or server is not broken, it doe's not need workarounds.
Workarounds can not help for broken applications any way, it is a useless
stuff and it infects code with "Observers".
Serge et al,
Further to my suggestion about using the Observer pattern for event
notification w.r.t. point 4 (below) I forgot to mention that it also has the
benefit of offering a compromise in the pro/anti recovery debate.
Existing contentious code designed to reclaim or test connections need no
Serge,
> 1. Remove existing abandoned recovery attempt code.
> 2. Log when connections are abandoned and do not add them back into the
> pool.
> 3. Optionally log stack trace of where abandoned connection was first
> grabbed.
> 4. Provide some kind of extensible connection object that could allow
a Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, July 21, 2003 4:51 PM
> Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
>
>
> > David Graham wrote:
> > >>I fess up, I am the guilty party who added the ability to trace
> > >
David Graham wrote:
That is not a good reason IMHO to prevent those who feel it is a very
important feature from including a sub class which supports this with
the DBCP release.
The fact that DBCP cannot reliably determine whether a connection has been
abandoned is a very good reason to not inc
> > So, what are these more effective ways to prevent pages?
>
> Not deploying code with resource leaks, training developers on proper
> resource cleanup, calling developers responsible for the resource leak
> in
> the middle of the night to help you fix the problem, etc.
I forgot one:
If apps
> > I strongly disagree. You getting paged due to someone's poor coding
> > abilities is outside the scope of DBCP. There are much more effective
> > ways of preventing pages than by developing a library that covers up
> > coding mistakes so that they persist indefinitely.
> >
>
> So, what are
t; <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Monday, July 21, 2003 4:51 PM
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
> David Graham wrote:
> >>I fess up, I am the guilty party who added the ability to trace
&g
David Graham wrote:
I fess up, I am the guilty party who added the ability to trace
abandoned
connections and recover them. ;-)
Sorry to jump in late on this. I have been busy with other things.
The motivation behind this was to allow a servlet container to continue
operating normally even if you
> I fess up, I am the guilty party who added the ability to trace
> abandoned
> connections and recover them. ;-)
>
> Sorry to jump in late on this. I have been busy with other things.
>
> The motivation behind this was to allow a servlet container to continue
> operating normally even if you ha
Noel J. Bergman wrote:
It appears clear that there are two camps, each with fairly strong views.
Personally, I believe that both camps can be accomodated in a way that
should satisfy both.
DBCP should focus on core pooling behavior related to connections and
prepared statements, and leave policy is
66 matches
Mail list logo
