A connection is being checked twice for being dead (by calling FConnections.Rollback) . Both when it is Acquired and when it is being returned to
the pool (see TConnectionPool.ReturnToPool and TConnectionPool.Acquire ).
Calling rollback is expensive.
I believe that TConnectionPool.ReturnToPool call is redundant. And removing it will not change the way applications actually work.
Thanks,
Yoni
TConnectionPool - Performance issue
-
- Platinum Boarder
- Posts: 1956
- Joined: 17.01.2011, 14:17
Re: TConnectionPool - Performance issue
Hello Yoni,
did you check that removing the call actually improves performance in your setup? Just out of curiosity: Which database / zeos driver do you use?
Best regards,
Jan
did you check that removing the call actually improves performance in your setup? Just out of curiosity: Which database / zeos driver do you use?
Best regards,
Jan
Re: TConnectionPool - Performance issue
Hi,
Sure. I removed the code and it does improve the performance. I'm using the PostgreSQL driver (connecting to server v13.2).
Doing a rollback is very expensive, as you have a full roundtrip to the server .
As aside note, there is also a bug that can lead to connection leakage when doing a rollback and the connection is set to AutoCommit, PostgreSQL throws an exception stating that an AutoCommit connection cannot be rolledback, then TConnectionPool.ReturnToPool marks this connection as unusable and obtains a new one while not closing or releasing the first
Sure. I removed the code and it does improve the performance. I'm using the PostgreSQL driver (connecting to server v13.2).
Doing a rollback is very expensive, as you have a full roundtrip to the server .
As aside note, there is also a bug that can lead to connection leakage when doing a rollback and the connection is set to AutoCommit, PostgreSQL throws an exception stating that an AutoCommit connection cannot be rolledback, then TConnectionPool.ReturnToPool marks this connection as unusable and obtains a new one while not closing or releasing the first