sebb wrote: > On 14/01/2010, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 1/14/10, sebb <seb...@gmail.com> wrote: >> > >> > On 14/01/2010, Phil Steitz <phil.ste...@gmail.com> wrote: >> > > Unless I am reading the output of the latest failures wrong or we >> > > are picking up the wrong hashcode (should be innermost delegate), >> > >> > It's currently the connection returned by getConnection(). >> > I'll fix that. >> >> >> >> Should actually be correct as is. As you recall from equals() discussion,. >> DelegatingConnection hashCode gets it from the >> innermostDelegate. System.idendityHashCode should pick this up. Could be >> overrriden somewhere, but I don't think so. >> > > System.identityHashCode() uses Object.hashCode(). > > Had I used conn.hashCode() it would have been OK, but I thought I > wanted to distinguish different "equal" objects. That was possibly > wrong.
Yeah, sorry, temporary brain deadness. The Delegating connection returned is new each time and you need to use the overridden hashCode to see if the underlying connection is the same. > > However, after fixing it to use the innermost delegate I ran a local > test with hold=wait and I could see the same hash being re-used. That is good. Consistent with subsequent Continuum runs. Phi > >> Phil >> >> >> > this is now looking like it could be a pool bug - allowing more than >> > > maxActive distinct connections to be simultaneously active. Need to >> > > look at this some more. It is worth temporarily modifying the pom >> > > to use pool 1.4 for a test. >> > >> > OK; I think we should see if there are duplicate hashes first. >> > >> > > >> > > Phil >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
