Hmm, I am not sure about this, the local variable fetch does not use any property of the Java Memory Model to make it gurantee to work. I would simply return 0 if the difference is negative. And of course making the last used value volatile.
Greetings Bernd BTW: for what is that idle time used? Am 05.10.2014 13:11 schrieb "Jacopo Cappellato (JIRA)" <j...@apache.org>: > > [ > https://issues.apache.org/jira/browse/POOL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Jacopo Cappellato updated POOL-279: > ----------------------------------- > Attachment: POOL-279.patch > > New patch with a comment that explain the reason a copy of the field is > taken; thanks to [~s...@apache.org] for the review. > > > Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis() > > ------------------------------------------------------------------- > > > > Key: POOL-279 > > URL: https://issues.apache.org/jira/browse/POOL-279 > > Project: Commons Pool > > Issue Type: Bug > > Affects Versions: 2.2 > > Reporter: Jacopo Cappellato > > Priority: Minor > > Attachments: POOL-279.patch, POOL-279.patch > > > > > > Under unlucky thread concurrency the getIdleTimeMillis() method of > DefaultPooledObject can return a negative value. > > I have attached a Junit test that fails most of the times and a simple > fix, that doesn't use synchronization: with this fix the Junit test always > succeed. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
