No. This is a completely different option that controls how long should the pool wait before telling client that there is no available instances in the pool (if the Wait option is set)
Btw next build will have smarter connection check timer period management:
It will take the expected connection expiration timeout and try perform the check twice as often, but not more often than once per 60 seconds and not less often than once per 600 seconds.
PooledClassFactory destroys timed out service instances. What happens with the db connection in this case depends on the concrete ADO.NET driver implementation.
It doesn’t do this. This service expects itself to be properly De-activated. Otherwise the connection is not returned to the pool, session is not properly released etc.
Connection Pool doesn’t know that the connection taken from it has been closed and destroyed already, so it thinks that someone still uses it. Eventually it ends up that the pool thinks that there is no more connections it does what it is configured for - waits for 10 minutes before raising an error that no connections can be acquired.
What you REALLY need to do is to use the Data Abstract instance properly and let the ConnectionManager do its work.
You need to override the InternalActivate and InternalDeactivate protected service methods and create new DataAbstractService instance + activate it in the former and deactivate service instance in the latter.
Both operations are really fast and are literally nothing compared to the time required to actually perform the database call, so there won’t be any performance hit