> Juozas wrote:
>
> > It is very dificult to find pooling
> > related bugs in application. May be
> > it has meaning to implement something
> > like "DebugPool" to help find problems
> > in users code. I can think about this,
> > if this idea is interesting.
>
> In the pool/dbcp implementation from which commons-pool/commons-dbcp is
> derived, probably the most useful diagnostic we found, especially for the
> kinds of problems Glenn seems to be having, is to track the number of
> connections being used by each thread (using a ThreadLocal variable), and
> logging or throwing an exception when that number is greater than 1. In
all
> cases I can think of when a thread is borrowing more than one connection
> from the same pool (or from mutliple pools) it is either a logic or design
> error.
>
> We ripped out that, and some logging, out of concern for the general case,
> but I like the idea of a DebugPool. Perhaps DebugPool could simply be a
> thin wrapper around an arbitrary pool, adding logging and related
debugging
> calls.
This idea is very dirty at this time:
1) "Remember" threat and stack trace then Thread obtains pooled object
2) Log stack trace if Thread "dead", but not returned object to pool.
It will not help for all situations, because the stack tracecan be always
the same for some applications,
But this kind of applications never have problems with pool :)
It is always possible to implement jdbc code in this way:
execute( SQL s, params[] p , Callback c ){
/* open */
/* execute */
/* finally close */
}
and use this method for all queries and updates
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
