On 5/31/06, Tom <[EMAIL PROTECTED]> wrote:
>> Since the sequence of objects in the stack is random, > > Umm, that statement is incorrect. The idle objects in a stack based > pool would have the stalest objects on the bottom. It may be random > with respect to the order the object were created but the order with > respect to when they were returned is very specific. Correct, I did mean random in light of the usage of the object; it is not like one object is borrowed preferred over another because of, say, better performance. The pool has no feedback logic where objects associated with lesser burdened resources have a higher borrow priority - if you get what I mean - of course there is an ordering according to "staleness" possible. Hmmmm, it would be an interesting add-on to the pool though, callbacks so the objects can be prioritized.
Hrm, pass the pool a Comparator and let it keep the internal idle object list sorted. But really any valid idle object should be just as good as any other valid idle object. I don't think you'd gain anything in the real world.
> Now, this deadlock issue goes away if the Pool never calls out to the > PoolableObjectFactory methods while it is holding it's internal > "PoolLock". I totally believe you :-) What the hell am I talking about? I don't know the source code at all. And I forgot to thank the developers for a great library!
I don't know either.
> Personally, I think the composite pool code in the trunk is quite > robust and solid. The current problem is it is not really any faster > than the existing pool implementations. Hm. Good to hear, I'll take a peak. Is performance an issue?
Yes and no. Pool itself rarely uses even 1% of cpu time for a request in a webapp. But since it's a bottleneck, especially when new objects need to be made that take a while to create (such as a connection to a DB), it can introduce latency and hold up a number of requests while they wait to borrow/return objects to/from the pool. End users tend to care about responsiveness measured by wall clock time over raw cpu time. Currently pool has a rather flat throughput curve as you add more CPUs. At work when we pay for quad cpu servers we want them to have an almost 4x performance over a single CPU server. Any code that gives less than a 2x performance increase for 4x the hardware is disappointing.
> I may punt this until Pool 3.0 where we require Java 5 and > the java.util.concurrent classes are available. Hm. Personally I love Java 5, but I can't seem to get all my clients to move. Forcing the pool library to 1.5 will probaby mean a lot of projects cannot follow.
My personal rule of thumb is to target two releases back from the current stable JVM.
Would using the original locking library (or -dare I say- embedding one or a few classes from that library) be an option?
Don't know, haven't looked into it or the licensing issues yet. -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
