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)
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
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,
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
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
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
12 matches
Mail list logo
