On 11/05/2011 11:31, Mark Thomas wrote: > On 11/05/2011 04:34, Phil Steitz wrote: >> On 5/10/11 7:26 PM, Phil Steitz wrote: >>> On 5/10/11 8:48 AM, ma...@apache.org wrote: >>>> Author: markt >>>> Date: Tue May 10 15:48:22 2011 >>>> New Revision: 1101516 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1101516&view=rev >>>> Log: >>>> Move to using LinkedBlockingDeque for the queue of idle objects. >>> Definitely simpler, cleaner code, but seems there will be no easy >>> way to enable fairness and some badly "unfair" stuff can happen when >>> clients get instances under maintenance. In theory, an unlucky >>> client could wait forever. Do we have any data on how "unfair" >>> LinkedBlockingDeque can be? ArrayBlockingQueue is an alternative >>> that does support fairness; but then I guess we lose LIFO/FIFO >>> control and probably performance. Any ideas how we could get >>> fairness, or at least some control over fairness to work? Another >>> thing to think about is whether clients are better off waiting for >>> the state change on instances under maintenance than getting back in >>> line for the next available instance. (I now see the fairness TODO >>> in TestGOP :) >> >> After looking quickly at the Harmony code for LinkedBlockingDeque, >> we may be able to solve both the 1.6 problem and fairness by >> bringing that source in and just making the ReentrantLock that it >> uses configurable to be either fair or not (as ArrayBlockingQueue >> does). Might be naive, but might work. > > I like it. A lot. Great idea.
Better still, it is faster than whatever Oracle wrote for Java 6 :) With this in place, DBCP is slightly faster than jdbc-pool for jdbc-pools checkout thread tests. This is only two microbenchmarks (there are lots of other tests where jdbc-pool is faster but I haven't optimized DBCP for those yet) but it is a promising sign. I just need to tidy up the code before I check it in. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
