"I don't think it is a bug.", he said.

So Mr Sun Tech support guy came back from vacation and finally find time to my query. He called and asking plenty of information which I had already provided in my email. The most important question asked was "Can you recreate it?"

An engage debate beings. The debate revolves around, if the person reporting the bug is responsible to prove that the problem happen or should the tech support people be responsible to prove that what i reported was due to the "Stupid user" syndrome. This is similar to how justice is implemented in US and Singapore. You are innocent unless proven guilty by the prosecution vs You are guilty unless the defense proof that you are innocent.

So after the debate. Yes I proofed the scenario is reproducible.
The steps are as follows.

Prerequisites:
Sun Application Server
Oracle DB. (I suspect that it would happen to other DB too.)

Steps in Sequence:
1) Limit the number of concurrent session for a particular db user to eg: 150.
2) Configure the min/max pool size to be the same and large number like 300.
3) Restart the server to have a clean start.
4) Notice that the server starts up fine and then access the application using the connection pool. This will kick start the initialization of the connection pool.
5) Then you will notice that the connection pool will initialize until it is 150. (as define by the DB concurrent session limit)
6) Using the Server monitoring feature, you can observe that the number of connection created was 150.
7) The DB should report 150 at this time too. The strange thing is that, although there are connection in the connection pool, none of them can be use by the application. The application requesting for connection will report that the SQL Exeception that the number of concurrent session for the DB user has exceeded.
8) Then request the DBA to up the number of concurrent session to 500. This is to simulate a situation which the server encounter problem when initializing the connection pool.
9) Try accessing the application again. This time the application will return with the correct and successful results.
10) However using the server monitoring feature, you will realize that the number of connection has exceeded the number which you define. In this example 300. The total number of connection created and in the pool is 450.

Conclusion:
The server failed to completely initialize the pool to the required size and the application server is not smart enough to detect that there are available connections which the web application can still use. When the problem was resolve, the pool is reinitialize. It failed to detect the current state of the connection pool and re-run the initialization process fully. It then establish the x+(steady state connections) where x is the number of connection previously initialized. Eat these! This is a bug. BUG BUG BUG I tell you.

There are however a few question marks. Is the problem caused by having a large number of connection? Is it cause by having the same min max values? If I need to find this out, might as well give me the source code and I fix it for them. Damn it, earn your pay Sun Support Staff. Where is your customer service Sun Microsystems!