Dirk> IMHO, I think that (small) components shouldn't
Dirk> log anything. They can contain debug statements that
Dirk> were used to develop the component and are left in because
Dirk> there might be a bug but logging... no. The pool component
Dirk> shouldn't log anything when you request something from an
Dirk> empty pool, it should just do what the API specifies, return
Dirk> null or throw an exception. The application should handle
Dirk> that situation and write some log message if the
Dirk> situation demands it.
I agree that for the specific case you cite the API contract is sufficient.
But allow me to provide some concrete examples of where logging (and not
debugging) is more useful. I'll follow your lead and use Pool as an
example:
Recall that the Pool component (and the DBCP component, which builds upon
it) has three distinct modes which determine the behaviour of borrow when
the pool is exhausted:
* FAIL - which causes the borrow call to fail immediately (returning null or
throwing an excecption, I believe the latter)
* BLOCK - which causes the borrow call to block (configurably for a finite
or indefinite amount of time), finally failing if that time expires
* GROW - which causes the pool to simply create and return a new pooled
instance
Now, there are several cases where I believe logging is quite useful here:
1. Note that BLOCK mode creates the possiblity of a deadlock condition in
the classic "dining philosophers" kind of way: Imagine two threads each of
which need to borrow two objects from the same pool. If the pool contains
exactly 2 objects, and each thread grabs one object, then they will both
block waiting for the the other to return the second object it needs.
Depending upon configuration and use, even if there are multiple threads
that each use multiple instances from the same pool, the actual deadlock may
be rare. But in the most common circumstances it is rather easy for the
pool to detect the potential for such deadlocks--it simply counts the number
of objects actively borrowed by each thread. Whenever this number is larger
than 1, there is some possiblity of a deadlock occuring.
It seems useful to me to be able to configure the pool to optionally track
this information, and to report when the situation occurs. Yet I don't want
to throw an exception or otherwise break the normal application
flow--there's no reason to force a failure when there is just a potential
for one.
2. When the pool is configured to BLOCK, if the size of the pool is not
tuned optimally, it is common for the pool itself to become a bottleneck in
the processing time (indeed, sometimes this is the intent). For example,
perhaps most of the borrow calls are blocking for a some extended period of
time, but not long enough for the request to time out. Again, I don't want
to force a failure in these conditions, but at the same time it seems like
the kind of thing I might want to know about. Logging an (optional) message
when the borrow method blocks is a convienient way of handling this.
3. Similiarly, no matter which mode I am running in, for tuning purposes it
is often helpful to know how much of the pool's capacity I'm using under
normal operation (Assuming you're not trying to throttle back the use of
some external resource, generally speaking the pool should be configured to
contain no more but no fewer than the number of objects that are borrowed
concurrently.) Logging provides a simple way of providing this information.
- Rod
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
