Hi,
I just wondered what the status of the following bug is:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35591
Basically this bug prevents one to create serializable connections with
connection checking and without auto commit for any oracle database. The
problem is that setting the
Hello John!
I do think I see certain (serious) issues
with the code, and I have started to compose
a comprehensive mail on this, but let us
please first discuss the
[dbcp] Do we need Referenceable?
thread I'm starting now as the outcome
of the discussion will influence greatly
what my
Have looked a couple of weeks ago
* jdbc2 part seemed out of operation to me (just can't go into a release)
I've seen a couple statements like this. No one presents any reasons
for their statement though. I started this pool and use it in
production, so have dual interest in hearing what
--- Serge Knystautas [EMAIL PROTECTED] wrote:
David Graham wrote:
This entire thread has been filled with reasons to not support closing
abandoned connections. If you need to have this behavior, you will
need
to customize DBCP for your apps because it should not be built in.
However,
. Bergman [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 7:43 AM
Subject: RE: DBCP status?
This entire thread has been filled with reasons to not support
closing
abandoned connections. If you need to have this behavior, you will
need
]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, July 02, 2003 7:43 AM
Subject: RE: DBCP status?
This entire thread has been filled with reasons to not support closing
abandoned connections. If you need to have this behavior, you will need
to customize DBCP for your apps
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 issues to specialized
--- Noel J. Bergman [EMAIL PROTECTED] 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
Some of the AbandonedTrace behavior is still necessary to implement
the JDBC specification. Connections still need to track outstanding
statements and results sets, which are closed by Connection.close().
Agreed, but the way it was implemented was completely wrong. The behavior
should
David Graham wrote:
I know how you feel. DBCP won't save you in these cases; training people
in the simple ways of cleaning up resources properly will.
Yeah, I have plans on how to spot these issues better ahead of time.
Also, just starting to use p6spy as my magic bullet in the short-term...
On Wed, 2 Jul 2003, Serge Knystautas wrote:
[snip]
For some reason there are people against adding commons-logging to DBCP.
I don't know of any good reason not to.
I think it's just because it's to keep the dependency tree thin. I
haven't been burned yet, but in some of my apps I have
On Thu, 3 Jul 2003 10:10 am, Craig R. McClanahan wrote:
* If you don't use C-L, then you're either going to mandate
some specific logging solution, or go without the benefits
of logging in DBCP. Neither of those choices seems like
a particularly good idea for a general purpose
--- Noel J. Bergman [EMAIL PROTECTED] wrote:
Some of the AbandonedTrace behavior is still necessary to
implement
the JDBC specification. Connections still need to track outstanding
statements and results sets, which are closed by Connection.close().
Agreed, but the way it was
Hello Serge!
Serge Knystautas wrote:
SK I agree trying to recover connections is bad. I've found it leads to
SK problems that don't show up during a test phase become very confusing
SK and challenging problems in production once under high-load.
SK The approach I took was this
SK a)
--- Serge Knystautas [EMAIL PROTECTED] wrote:
David Graham wrote:
The problem was that DBCP was trying to track and recover abandoned
connections. This isn't just an implementation problem, it's a
philosophy
problem. Pool semantics dictate that client applications behave
properly
when
b) if this threshold is exceeded, you close the connection. The value
of trying to return it to the pool is minimal, while the downside of
returning a mid-transaction/statement connection to a pool is very bad
and nearly impossible to track down.
DBCP should not close connections that
Hello David!
DG DBCP should not close connections that have been borrowed from the pool.
DG It should only log a possible error when the configured time limit has
DG been exceeded.
What do you think, should this overtimed connection still be
considered active for the purpose of enforsing
--- Anton Tagunov [EMAIL PROTECTED] wrote:
Hello David!
DG DBCP should not close connections that have been borrowed from the
pool.
DG It should only log a possible error when the configured time limit
has
DG been exceeded.
What do you think, should this overtimed connection still be
:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 10:40 AM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re[2]: DBCP status?
Hello David!
DG DBCP should not close connections that have been borrowed from the pool.
DG It should only log a possible error when the configured time limit
responsibility.
David
- Mark
-Original Message-
From: Anton Tagunov [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 10:40 AM
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re[2]: DBCP status?
Hello David!
DG DBCP should not close connections
Developers List' [EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 5:07 PM
Subject: RE: Re[2]: DBCP status?
Entering in the middle here...
I added a logging statement in my pool that reports overdue connections
and
it's been helpful in alerting us to problems. One thing to consider is
adding a hook
David Graham wrote:
The approach I took was this
a) support an optional max-active time threshold, which means there is a
time limit to how long a connection can be marked as in use.
There is a maxActive property of BasicDataSource that defines the maximum
number of open connections. Adding
--- Serge Knystautas [EMAIL PROTECTED] wrote:
David Graham wrote:
The approach I took was this
a) support an optional max-active time threshold, which means there is
a
time limit to how long a connection can be marked as in use.
There is a maxActive property of BasicDataSource
Serge,
I *need* the pooler to close connections that have been borrowed from
the pool and forgotten to be closed. Can you give a) reasons why not to
close them because of an optional parameter and b) suggested workaround?
Why? I can think of a couple of reasons you might give, but I'm
ResultSet rs;
try {
con = magicGetConnection();
//stuff
} catch(...) {
} finally {
try {if (rs!=null){ rs.close(); rs=null; } } catch(Throwable ignore){}
try {if (ps!=null){ ps.close(); ps=null; } } catch(Throwable ignore){}
try {if (ps!=null){ con.close(); con=null; } }
Hi, All!
1) A side-note
It would be really more easy if this discussion was
held somewhere on db-commons, really :-)
2)
PS The EAI or network infrastructure, for example, behind one of the
PS apps could cause it to grind to a halt, effectively orphaning any
PS connections that it has open,
:
Subject: Re[2]: DBCP status?
30/06/2003
I think we've had this discussion before.
But I'll weigh in with my 2c again because I still feel strongly about it..
Craig says:
I do not believe there is any fundamentally sound algorithm that a
connection pool can use to detect when a connection has truly been
abandoned and is thereby
Developers List [EMAIL PROTECTED]
Sent: Monday, June 30, 2003 12:47 PM
Subject: RE: DBCP status?
I think we've had this discussion before.
But I'll weigh in with my 2c again because I still feel strongly about
it..
Craig says:
I do not believe there is any fundamentally sound algorithm
Hello Ken!
There have been very strongly argumented opinions
that the pool should do nothing of the sort, but
I'd like to go to the bottom of discussing other
alternatives too.
KH * emulates a legal timeout from the database server
I have been stricken with the beauty of approach
you have
Pool doe's not need locks on connection objects, synchronized can be used
for wait/notifyAll,
but it needs monitor of some global object. Pool must never return the
same connection
for different threads, but connection can be fail-fast itself,
it is not a very big overhead for connection
I wouldn't bother with the synchronization -- closing the socket (which would
(probably) be the effect of con.close()) would propagate the event. Obviously this
would be driver dependent, and at best is still a bad thing to do -- to re-iterate,
I'd only want DBCP to, at most, log abandoned
Hello Juozas!
JB Pool doe's not need locks on connection objects, synchronized can be used
JB for wait/notifyAll,
JB but it needs monitor of some global object. Pool must never return the
JB same connection
JB for different threads, but connection can be fail-fast itself,
JB it is not a very big
I have been stricken with the beauty of approach
you have proposed, indeed its nice to emulate
a server timeout :-))
I can see how this would appeal, allowing DBCP to impose its own timeout, however IMO
it would still not allow DBCP be able to reclaim the connection,
Rather it would have
But, I've got a feeling that we're talking different languages here!
In fact I was discussing Ken Horn's idea that the pool could
* after a connection has been grabbed but not released,
for say 10 minutes
* forcibly close the underlying real connection
(thus freeing db server's
David Graham wrote:
The problem was that DBCP was trying to track and recover abandoned
connections. This isn't just an implementation problem, it's a philosophy
problem. Pool semantics dictate that client applications behave properly
when checking out and returning pool resources. The pool is
I do not believe there is any fundamentally sound algorithm that a
connection pool can use to detect when a connection has truly been
abandoned and is thereby suitable for recovery.
If we did not have a pool, the server would eventually (a) run out of
connections, possibly impacting other
--- Noel J. Bergman [EMAIL PROTECTED] wrote:
I do not believe there is any fundamentally sound algorithm that a
connection pool can use to detect when a connection has truly been
abandoned and is thereby suitable for recovery.
If we did not have a pool, the server would eventually (a) run
That is most likely why people want DBCP to recover connections but again
this is beyond the scope of DBCP. Fixing the applications to manage their
resources appropriately is the solution in this case.
+1
I prefer to remove all resource management workarounds from DBCP and use
fail-fast
--- Phil Steitz [EMAIL PROTECTED] wrote:
David Graham wrote:
--- Noel J. Bergman [EMAIL PROTECTED] wrote:
David,
I hope that you have not gotten the impression that I am arguing with
you.
Nope, I was just stating my point of view :-). I will continue to
argue
against
- Better support/debugging for forcing connections closed after being
open for too long
This is exactly what got DBCP into trouble in the past. I'm -1 on
providing any ability in DBCP to close lost connections. DBCP should
provide the ability to *log* when it detects a resource leak
--- Noel J. Bergman [EMAIL PROTECTED] wrote:
- Better support/debugging for forcing connections closed after
being
open for too long
This is exactly what got DBCP into trouble in the past. I'm -1 on
providing any ability in DBCP to close lost connections. DBCP should
provide the
That's all well and nice until a request fires a condition where it doesn't
close the connection and takes down the server or makes all requests fail due
to an exhausted pool. Which can only be fixed on the short term by a
webserver restart. Which is what a sysadmin will due, report it in a log
The code was buggy and added complexity both in and out of the
AbandonedConnectionPool.
Some would argue that recovering from programmer error is not an
appropriate role for a component like DBCP, and for what it's worth, I
think I'm probably one of those.
That said, I think changing dbcp/pool
--- Rodney Waldhoff [EMAIL PROTECTED] wrote:
The code was buggy and added complexity both in and out of the
AbandonedConnectionPool.
Some would argue that recovering from programmer error is not an
appropriate role for a component like DBCP, and for what it's worth, I
think I'm probably one
--- Tim Funk [EMAIL PROTECTED] wrote:
That's all well and nice until a request fires a condition where it
doesn't
close the connection and takes down the server or makes all requests
fail due
to an exhausted pool. Which can only be fixed on the short term by a
webserver restart. Which is
On Sat, 28 Jun 2003, Noel J. Bergman wrote:
Date: Sat, 28 Jun 2003 14:34:05 -0400
From: Noel J. Bergman [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: DBCP status
Hi, all!
JMcN I am the primary developer of the jdbc2pool and cpdsadapter packages.
JMcN I do not see any reason to merge the code into one package with the rest
JMcN of dbcp. They seem packaged appropriately to me. The main thing that
JMcN needs to be done here is to rename the jdbc2 in the
Hello Serge!
SK Is anyone working on DBCP or planning another release anytime soon?
SK It's been almost a year, and the project seems pretty inactive.
Lurker's 0.02$
Have looked a couple of weeks ago
* jdbc2 part seemed out of operation to me (just can't go into a release)
* all the rest
DBCP has 5 open bugs. I recently was looking at 18905 and modified some
test code so that it is possible to reproduce. I did not get to the
solution, so the test is not activated.
It looks like 20649, could be resolved in some fashion by removing the
use of AbandonedObjectPool. Getting rid of
--- John McNally [EMAIL PROTECTED] wrote:
DBCP has 5 open bugs. I recently was looking at 18905 and modified some
test code so that it is possible to reproduce. I did not get to the
solution, so the test is not activated.
It looks like 20649, could be resolved in some fashion by removing
Serge,
I'm using DBCP in a production environment. It actually does support
validation queries to detect whether a connection is bogus or not.
You just need to call setValidationQuery() on the
PoolableConnectionFactory, and enable testOnBorrow on the ObjectPool you
pass to the DBCP init stuff.
On a related note, does anybody know what the status of
PreparedStatement pooling is in the latest DBCP release? It seems
broken to me, but I might be doing something wrong.
It doesn't appear to be implemented yet.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18012
David
-- Mark Lewis
On
Howdy,
Yes, but that doubles the # of SQL statements. And I actually have
probably no more than 8 SQL statements in total (all prepared), so the
issue is not the SQL but the connection.
Is there another way to check that a connection is bad, other than a
validation query? AFAIK this is the
Shapira, Yoav wrote:
I wouldn't rush to declare DBCP dead. Database connection pooling is
not exactly the most revolutionary development area right now: DBCP is
good at what it does, is being used widely, and I personally am not
aware of anything that required a DBCP release within the past year.
Howdy,
Since James really does need a new connection pooler, and I'm stuck
having to invest some time into making **some** database pooler more
robust, is the DBCP project open to this? I'm not sure if there are
any
I'm positive no one would oppose you contributing and working on it ;)
-
Serge Knystautas wrote:
Since James really does need a new connection pooler, and I'm stuck
having to invest some time into making **some** database pooler more
robust, is the DBCP project open to this? I'm not sure if there are
any committers remaining, or what exactly is the next step.
Noel J. Bergman wrote:
Martin Poeschl [EMAIL PROTECTED] wrote:
dbcp is still used by torque and other projects ...
i'm also interrested in maintaining the code ..
how's about moving the package to db-commons??
Martin, so long as we get commit access, does it really matter which module?
I
existing apache committers have traditionally had few problems about being
elected committers here so access shouldn't really be a problem.
i'd say that there will probably be quite a difference in atmosphere
between the two sub-projects. developing in the jakarta commons means
putting up with
dbcp is still used by torque and other projects ...
i'm also interrested in maintaining the code ..
how's about moving the package to db-commons??
Martin, so long as we get commit access, does it really matter
which module? I view location as orthogonal.
db.apache.org is a good location
Noel J. Bergman [EMAIL PROTECTED] writes:
Martin Poeschl [EMAIL PROTECTED] wrote:
dbcp is still used by torque and other projects ...
i'm also interrested in maintaining the code ..
how's about moving the package to db-commons??
Martin, so long as we get commit access, does it really matter
I think that poolman had been end-of-lifed, and many of it's ideas went into
DBCP.
Eric
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 5:16 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP status?
On Mon, 23 Jun 2003, Serge
: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 5:16 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP status?
On Mon, 23 Jun 2003, Serge Knystautas wrote:
Mark Lewis wrote:
Serge,
I'm using DBCP in a production environment. It actually does support
validation
existing apache committers have traditionally had few problems about being
elected committers here so access shouldn't really be a problem.
I didn't expect that there would be a problem.
i suppose that the first step should really be to propose
a VOTE to elect noel as a commons committer.
Subject: Re: DBCP status?
did geir once suggest bringing poolman to apache?
does anyone remember what happened about that?
There was not enough support for the move.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
, 2003 5:16 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP status?
On Mon, 23 Jun 2003, Serge Knystautas wrote:
Mark Lewis wrote:
Serge,
I'm using DBCP in a production environment. It actually does support
validation queries to detect whether a connection is bogus
existing apache committers have traditionally had few problems about being
elected committers here so access shouldn't really be a problem.
Noel, forgive my ignorance but are you an existing committer? I'll nominate
you to the commons based on Robert's apparent faith in you ;-).
i'd say that
David Graham wrote:
I took a crack at fixing DBCP for Struts 1.1 and decided it was in such
bad shape that we (Struts) should just drop it. If other people are
willing to fix and support it, I'm +1 on moving to db-commons.
Here is my wish list for DBCP in no particular order:
Thanks David.
existing apache committers have traditionally had few problems about
being
elected committers here so access shouldn't really be a problem.
Noel, forgive my ignorance but are you an existing committer? I'll
nominate you to the commons based on Robert's apparent faith in you ;-).
No
David Graham wrote:
I took a crack at fixing DBCP for Struts 1.1 and decided it was in such
bad shape that we (Struts) should just drop it. If other people are
willing to fix and support it, I'm +1 on moving to db-commons.
Here is my wish list for DBCP in no particular order:
Thanks David.
existing apache committers have traditionally had few problems about
being
elected committers here so access shouldn't really be a problem.
Noel, forgive my ignorance but are you an existing committer? I'll
nominate you to the commons based on Robert's apparent faith in you
;-).
No
DBCP is very inactive. Struts dropped it from the distribution due to the
lack of development support.
David
Is anyone working on DBCP or planning another release anytime soon? It's
been almost a year, and the project seems pretty inactive.
I was trying to integrate DBCP into James this
72 matches
Mail list logo
