Atomikos Forum

Hello everyone, and great job on the library. It has certainly helped us a lot in our project.

Browsing through the source (version 3.6.0), I came accross something that really caught my attention... The connection pool seems to have an interpretation of minPoolSize different from that which is common in other libraries...

I would have expected the minPoolSize argument would determine the minimum size of the whole connection pool, however, for what I can see in ConnectionPool.shrinkPool, it's taken to be the minimum number of available connections to keep. If it's set to 20, and there are 5 non-available connections, the pool will be at least 25 connections, not 20...

I found this puzzling... it's against the usual aception of minPoolSize, and is actually causing us some issues with MySQL... you will see, MySQL fails with a CommunicationException if it receives a query from a connection that has been inactive for a time longer than a server variable 'wait_timeout' (default to 8 hours). Since Atomikos keeps unused connections above the intended absolute minimum, we find that every day, when the traffic goes up again after the low of the night, all these connections kept alive in the pool though unneeded fail and are destroyed and recreated, but giving an ungly exception to our code for manual reattempts.

This could be easily changed by editing line 201 from:

int maxConnectionsToRemove = availableSize() - properties.getMinPoolSize();

to

int maxConnectionsToRemove = connections.size() - properties.getMinPoolSize();

Is there any reason for this not being the case?

Thanks in advace.

Hi,

Thanks for the tip; this suggestion makes perfect sense.

Let us have a look at this to make sure, and if ok we'll include this in the next build.

Cheers!

Thanks for the quick reply. I hope my contribution is of help. Please let me know as soon as you look carefully into this. So far I have patched my jar with the proposed fix, and doing some tests.

Hi,

I've scheduled this for inclusion in our 3.6.2 release (it should be ok unless we still decide to reject for unexpected problems).

Thanks again.

Guy