I am currently working on this. I have a problem with entity pool. It is in the case of reclaim is true. There is one case when the EntityInstancePool will not send back the instance to the pool : when EntityInstancePool.free() is called inside a transaction, here the instance will be thrown away. So if I change the counting algorithm to take into account how many instance are currently in use, I may come to a point where I will never come back to the MaximumSize because some instances will be lost.
After looking further, this problem will also arise with stateless session bean in case of errors (StatelessSessionInterceptor.invoke()). Could we just NOT verify the maximumsize when pushing back to the pool and eventually have more instances in the pool that MaximumSize. The StrictMaximumSize would solve the problem when people really need it ? Vincent. > There is another issue with how the feeder interacts with the > pool. The getCurrentSize is really the pool free instance > count. Only on startup is this also the pool count. After the > pool has been filled once, (MaximumSize - getCurrentSize) is > no longer how many instances need to be added to the pool. > Say MaximumSize is 10 and the pool is filled by the feeder. > Next 10 clients invoke methods concurrently and take the pool > free count to 0 and getCurrentSize is also 0. The feeder then > wakes up and puts 10 more instances into the pool. The client > invocations next complete and all 10 instances are discarded > as the pool is seen to be full. The AbstractInstancePool is > not counting instances correctly when another thread is > adding instances. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
