On 9/27/14 6:04 AM, Gary Gregory wrote: > In org.apache.commons.pool2.impl.DefaultPooledObject.getActiveTimeMillis(), > I see: > > // Take copies to avoid threading issues > long rTime = lastReturnTime; > long bTime = lastBorrowTime; > > But isn't is the case that the object could be returned and borrowed again > between the two lines? Unlikely but possible? I think the following code accounts for this race. If a borrow-return were to sneak in between the two lines above, the values would end up out of sequence, i.e., we would have rTime < bTime. That would cause the check that follows to fail and rTime would be replaced by System.currentTimeMillis() in the computation. This would introduce a little error (I wonder if it would be better to just re-read the - volatile - value of lastRturntime here), but not much. Note also that this kind of thing could only happen if a client were holding a reference to a DefaultPooledObject and calling the (public) method directly. Internally, PooledObjectState generally guards against this kind of race. The only internal use is in returnObject, which uses state to prevent interleaving of this kind. Factory methods that may use this method will in general be similarly protected.
Phil > > Gary > > On Sun, Aug 31, 2014 at 11:09 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> We have fixed a few bugs and made some enhancements since 2.2 and I >> think we should cut 2.3. I will volunteer to RM. I will start >> rolling RCs from trunk around the end of this week. I don't see any >> of the current open bugs against 2.x as blockers. I may implement >> the request in POOL-272 (or gladly accept a patch), but I think this >> can wait for 2.4. Patches, beautification, late-breaking bugs >> welcome. >> >> 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
