c3p0 defaults are not exploiting the power of c3p0 reliability

Committed a patch with the following changes:

According to Simple advice on Connection testing:

• If you know your driver supports the JDBC 4 Connection.isValid(...) method and you are using c3p0-0.9.5 or above, don't set a preferredTestQuery. If your driver does not support this method (or if you are not sure), try SELECT 1 for your preferredTestQuery, if you are running MySQL or Postgres. For other databases, look for suggestions here. Leave automatedTestTable undefined.

• Begin by setting testConnectionOnCheckout to true and get your application to run correctly and stably. If you are happy with your application's performance, you can stop here! This is the simplest, most reliable form of Connection-testing, but it does have a client-visible performance cost.

So, following the advice:

• PreferredTestQuery is disabled

• set TestConnectionOnCheckout = true by default

I tested Initial Client Setup, and some big reports, and the performance cost mentioned was not visible, in my tests the execution time was the same.

However, I found the impact of these changes in the application reliability are enormous.

With those changes the webUI of iDempiere can support a database reboot without being noticed by users - of course running processes or reports are broken with an error message, but in general the application behaves very well.

That means also supporting better the automatic promotion of a replica database in case the master fails (as promised by AWS for example).

Another test done was being able to kill a postgres backend running wild on CPU - and the application is still stable.
Samely is possible to kill postgres backends holding locks.

IMPORTANT NOTE:
Current servers will not adopt this change - it requires manually modifying the file PostgreSQL/pool.properties or Oracle/pool.properties
The required change is to set to true the variable

Regards,

Carlos Ruiz