That would be quite difficult to handle on application side.
Two connection pools means two datasources, which need to be selectively
injected into the business logic. When the same business logic is handling 100
or 100000 rows, it's difficult to find a place to decide which datasource to
use.
Robert
From: Gary Gregory <garydgreg...@gmail.com>
Sent: Montag, 29. Juni 2020 23:37
To: Commons Developers List
Subject: Re: [DBCP] poolPreparedStatements
You can do this today by using two connection pools, one configured with
statement pooling, and the other not (which is the default).
Gary
On Mon, Jun 29, 2020, 16:36 Robert Paschek <robert.pasc...@comm-unity.at>
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
>
