commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: Re[2]: DBCP status?
Date Tue, 01 Jul 2003 15:48:41 GMT

It is nothing bad to add some logging to pool, but no workarounds.
Application must work with any pool implementation and not to depend on
workarounds in pool.
But I see nothing bad if application uses resource manager (It is not a
pool) and *never* closes connections,
connection returned from this kind of manager must throw Exception on
"close".
It is very bad thing to break contracts in stable componnents, just for some
crapy application support.
Read arhives, it was discussed a lot of times in [dbcp].

----- Original Message -----
From: "Ford, Mark" <mford@quelsys.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
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 that allows you to borrow a connection without generating
> these errors if you know that you'll be using the connection for a long
> time. For example, I have some background jobs that run and might use a
> connection for upwards of 30 minutes or more. These shouldn't be grouped
in
> with the same requests to my web app which should only need a connection
for
> a few seconds at most. Perhaps too specialized of a requirement, but it
> works for me ;)
>
> Also, I went as far as wrapping the Connection object returned from the
> DriverManager in my own so it could keep track of Statements that it
created
> to ensure that they get closed. When the borrowed connection is returned
to
> the pool it will log any open statements and the corresponding stacktrace
> for their creation and this has eliminated any statements being left open.
> This type of overhead is only necessary to weed out any mistakes early on
> and should be turned off for production code.
>
> - Mark
>
> -----Original Message-----
> From: Anton Tagunov [mailto:atagunov@mail.cnt.ru]
> Sent: Tuesday, July 01, 2003 10:40 AM
> To: Jakarta Commons Developers List; dgraham@apache.org
> 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 has
> DG> been exceeded.
>
> What do you think, should this overtimed connection still be
> considered "active" for the purpose of enforsing
>      WHEN_EXHAUSTED_FAIL or
>      WHEN_EXHAUSTED_BLOCK?
>
> Should the active connection counter rather be decreased
> by 1 once a connection overtimes?
>
> SK> c) support an optional debug step that will create a Throwable when
> SK> getConnection is called.  Then if the max-active threshold is hit, we
> SK> can print the stack trace of where the aged connection was grabbed,
and
> SK> in development/testing, quickly resolve the errant connection.
>
> DG> I'm ok with this as long the stack trace isn't logged like an
exception.
>
> DG> It will be confusing for people to see a stack trace that isn't really
> DG> associated with an exception so the message should indicate that it's
> DG> identifying a possible connection leak location.
>
> We can envent some special exception, something like
>
>     ConnectionOvertimeDetected
>
> or smth better, but give it such a descriptive name and message
> that would save the user from confusion.
>
> Or we could create a cascading exception that would have
> a getCause() method that would return the original exception
> as the root cause (it is in some sense a root cause)
>
> - Anton
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.23


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message