during the last few weeks we experienced some problems with session bean instantiation.
in the past we used default session bean pool, ThreadlocalPool. this pool implementation creates instances for every newly created thread, but these instances seem to never be destroyed, not even if the threads, they were created for, die.
so we tried StrictMaxPool pool implementation and set a maximum of 100.000. with this pool we see much less bean instances, because the pool creates them only if there are no free instances left. existing beans (released earlier) get reused later, allthough they are not destroyed until container/ server shuts down.
a simple scenario: in the morning 200 users log in and read their private messages. they all start working at 8 a.m. and they are using mostly the same services. every single user needs one bean instance for one request and because all users request concurrently, StrictMaxPool creates 200 instances. later the users have lunch, so no one fires request to the server, all beans (200!) are released and waiting in the pool. but because StrictMaxPool does not destroy beans, the 200 instances are kept in server vm/ heap all the day (until shutdown!).
we think this behaviour is a waste of resources! a pool should destroy instances if there a more instances in the pool than we want to reserve for further usage. because later the day our 200 users will almost never produce 200 concurrent requests again, we would like to configure the pool to just keep a maximum of 50 beans.
so my questions are:
1) why are instances not destroyed by StrictMaxPool? there is an idea of destroying instances in StrictMaxPool.release, but because pool.size will never be more than maxSize (an attemp to get one more bean always fails!), remove is never called!?
2) is there a pool implementation that destroys instances and just holds a configurable amount of beans? or do we have to implement it on our own (TolerantMinPool ; ))?
3) ?some more suggestions?
thanks in advance