Hi Robert,
Glad to see you're making good progress.
I) remove instances that are in use??
There is an unwritten rule that the Pool should remove its pooled instances whenever it is destroyed. StrictMaxPool doesn't follow this yet.
The Pool itself gets destroyed on undeploy or shutdown. In essence it means that the application will be tidied up a bit cleaner.
II) how to synchronize pool?a) InfinitePool and StrictMaxPool do not use synchronized methods, but synchronized statements for changes in the pool structure. i tried to adopt this for my pool. but i wonder if synchronized methods would also do the trick? or could it cause a bottleneck??
b) i checked sources of pool implementations in JBoss6. i noticed that org.jboss.ejb3.AbstractPool uses AtomicInteger to count create() and remove() while JBoss4 used a primitive instead. should a adopt this as well??
A Pool is called concurrently and thus thread safety must be implemented manually. Each synchronized block / method is a bottleneck for all incoming calls and should be kept to a minimum. Also because synchronized is an unfair lock on the pool, it leads to a high deviation in response times. ThreadlocalPool for example has the objective to keep thread locking to a minumum, thus giving the best throughput. Based on a pools requirements a choice must be made for modifying shared data: atomic, unfair lock or fair lock.
The counts in JBoss AS 4 are wrongly implemented and this was fixed. (See https://issues.jboss.org/browse/EJBTHREE-2155.)