On Jan 3, 2008 12:40 PM, Mark Thomas <[EMAIL PROTECTED]> wrote: > Christoph Kutzinski wrote: > > - creating a new object means the pool is exhausted which in turn usually > > means that we have a high-load situation. > > - creation of new objects is expensive (probably even more in high-load > > situations). This is why we originally used the pool > > - so in conclusion it is probably a bad idea to create multiple object in > > parallel > > I don't see how serializing object creation can help performance. If you > have a test case and some numbers that show otherwise, I would be very > interested in taking a look. > > If you are really worried about the cost of object creation then you can > configure the pool to create all the objects at start-up and block until a > free object is available. >
Thanks for the feedback, Christoph; but I agree with Mark. I suspect most pool users keep the default whenExhaustedAction, which is to block. That means that objects get created a) on demand, when there are no idle instances, but maxActive has not been reached b) when addObject is invoked to prefill or augment the idle object pool explicitly or c) when minIdle is set and the idle object evictor runs. Even when a) happens during a load spike, it is better to do the makes in parallel, especially if there is some latency involved and there are resources available to process the makes in parallel (which will be the case in, e.g. a database connection pool). This is all assuming that there is good synchronized control over the number of makes. (See post to follow.). As Mark said, if makes are *very* expensive, you can prefill and then configure the pool to block. Phil > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
