Hi linoops,
Thank you for your answer.
Well this is what I thought for a while. But right now I�m little bit older and I start doubting those benefits. I seriously doubt that ther is any overhead involved in creating ejb instances and to compare this with jdbc connections is not the best example. To create a connection is a very costly operation. It might take probably 100-200ms, depending upon many factors like network, whether the container tests the connection, etc. However building an empty ejb instance will always take about � 0ms. Probably not the way the container creates them today, using reflection and the Class.newInstance call, but just calling the appropriate constructor.
As for destroying those instances I�m neither very sure what�s the benefit either.
Java is very mature and provides several garbage collector algorithms that are very performant. Hence allowing java to handle both construction/destruction of the ejbs instances looks to me like a very good choice as well.
I think what I�m suggesting is this: allow clients to create ejb instances on demand and let the garbage collector destroy them like any other java objects.
Still believe that instance pooling brings that much?