> On Jun 30, 2020, at 2:36 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> How about clearStatementPoolOnReturn.

+1

Phil
> 
> You do not need to say "Prepared" in the name IMO since we only pool
> prepared statements. The above name actual says what happens when.
> 
> The full version of that name if you want to be extra specific would be
> clearPreparedStatementPoolOnConnectionReturn.
> 
> Gary
> 
>> On Tue, Jun 30, 2020, 16:59 Robert Paschek <robert.pasc...@comm-unity.at>
>> wrote:
>> 
>> ​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
>> 
>>> 
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to