unnecessary manual control timeout when get connection because it's support by c3p0 lib
Description
in DB_PostgreSQL.getCachedConnection has a code block to control: time out, retry, and protect system don't so busy.
about time out, retry: can use acquireRetryAttempts, acquireRetryDelay, checkoutTimeout of c3p0 library
about "protect system don't so busy" current logic as below: when busy connection near maxConnection (now near = 0.9%), will don't immediately request a new connection just delay for some seconds (this value get by random). it's unnecessary, because it's role of acquireRetryAttempts, acquireRetryDelay, checkoutTimeout and it let system hang when near to maxConnection, don't use max ability of system. image, max connection is 100, at heavy load, 90 connection is busy, for get a new connection, will must waiting for some seconds event system design for run good with 100 connection
for test this condition: 1. change some value in pool.properties as below MaxPoolSize=3 InitialPoolSize=2 MinPoolSize=2 MaxStatementsPerConnection=3 2. run server 3. now, when we open a window or special info window. it's very take time. even busy connection is 2, we still has a available free.
Mr wdyt about this issue?
Environment
None
Activity
Show:
Carlos Ruiz August 22, 2020 at 6:06 PM
Edited
Hi , I think the idea sounds nice and it can be implemented easily in implementations that require it as is just to change the pool.properties on the server.
It sounds like an interesting idea for a wiki documentation page.
As per the validation in DB_PostgreSQL and DB_Oracle - I think is OK, it can be seen as an extra effort in case the connections go wild.
From my experience the number of allowed connections must be configured high enough to never reach that 90% mark - and every time I see an installation reaching that point is because of a connection leak that must be solved.
Regards,
Carlos Ruiz
Carlos Ruiz October 5, 2015 at 11:49 AM
Hi , can you please upload a patch with your proposal, and if possible you can point me to a test case where the difference can be tested.
in DB_PostgreSQL.getCachedConnection has a code block to control: time out, retry, and protect system don't so busy.
about time out, retry: can use acquireRetryAttempts, acquireRetryDelay, checkoutTimeout of c3p0 library
about "protect system don't so busy" current logic as below: when busy connection near maxConnection (now near = 0.9%), will don't immediately request a new connection just delay for some seconds (this value get by random).
it's unnecessary, because it's role of acquireRetryAttempts, acquireRetryDelay, checkoutTimeout and it let system hang when near to maxConnection, don't use max ability of system.
image, max connection is 100, at heavy load, 90 connection is busy, for get a new connection, will must waiting for some seconds event system design for run good with 100 connection
for test this condition:
1. change some value in pool.properties as below
MaxPoolSize=3
InitialPoolSize=2
MinPoolSize=2
MaxStatementsPerConnection=3
2. run server
3. now, when we open a window or special info window. it's very take time. even busy connection is 2, we still has a available free.
Mr wdyt about this issue?