Thanks for the implementation hints. I'm willing to look into this.
Can you think of a better propertyname than
limitPreparedStatementPoolToConnectionUse? While the meaning is clear (at least
to me), it's also quite long.
Robert
From: Phil Steitz <phil.ste...@gmail.com>
Sent: Dienstag, 30. Juni 2020 21:07
To: dev@commons.apache.org
Subject: Re: [DBCP] poolPreparedStatements
On 6/29/20 12:17 PM, Robert Paschek wrote:
> Hello,
>
> DBCP has a feature to pool PreparedStatements for the lifetime of a
> connection.
> This results in cursors being open and locks in the database for a long time,
> which could cause problems with administrative tasks in the database. That
> why I would prefer this pool to be more short-living, that means that the
> pool is filled while the application is using the connection und cleared
> when the application is returning the connection to the ConnectionPool. This
> way the application can still benefit from the Statement-cache in mass
> operations, without creating headaches for database admins.
>
> I would suggest an additional setting like
> limitPreparedStatementPoolToConnectionUse or something similar.
>
> What do you think?
>
> Regards,
> Robert
One way to workaround the need to periodically clean up would be to
either set maximum lifetimes on connections or periodically invalidate
them. That would force the underlying PoolingConnections to be closed,
which would in turn cause the statement pools to be closed.
The feature request sounds reasonable to me. For anyone interested in
creating a patch to implement this, here is a way that might work to
implement it:
Connections that pool statements are PoolingConnections. Add a property
to this class to determine whether or not to clear the statement pool
when a connection is returned to the pool. Override
DelegatingConnnection's passivate method to first call super() but then
examine the property and if so configured, clear (not close) the
statement pool. Modify PoolableConnectionFactory to set the property
and BasicDataSource to pass it in.
Probably best to open a JIRA for this. I don't have time to work on it
now, but I would be willing to review PRs.
Phil
>
