> From: Vincent Massol [mailto:[EMAIL PROTECTED]] > > > From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > Yes, I thought about that. But then it creates new complex questions > such as : > - when do objects that are not released return to the pool and how do > you implement it
Never. They are gc'ed. > - it adds parameters to the application configuration Yes, but you can go with reasonable defaults. > So yes, if we cannot do anything else, we will use poolable components > but I'd rather not if I can find an alternative that is good enough. > > Isn't there synchronization also involved in pooling components ? ;-) Yes, but you will not have to create the components over and over again. The gain here is, I think, greater than the loss you have by synchronizing. Basically, I'm trading synchronization times for object creation times. > But yes, you are right, preallocating all needed resources is the only > way to guarantee response times ... Tried ThreadLocal variables? Gettin' uglier by the second, but 99.97% is a nightmare. All you need is a single GC run by the VM, and you're out of margin... /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
