On Tue, Jan 23, 2024 at 11:35 AM Phil Steitz <phil.ste...@gmail.com> wrote:
> To make it easier to follow and find later, let's move the discussion > started in [1], [2] here. > > The request made in the Jira [1] and implemented in the PR [2] to send > beginRequest and endRequest messages to drivers seems reasonable to me, but > just implementing unilaterally by default is probably not the best thing to > do. > > Summarizing discussion so far (Gary, Bernd, meedbak, pls fix any errors): > > 0) The spec is vague and drivers seem to do different kinds of things or > make different kinds of assumptions based on these messages. There are > some references in > [2] . > > 1) There is potential to reduce the activate/passivate overhead when we > can safely rely on these messages to maintain connection attributes. > > 2) It's not obvious when we should be send the messages. Borrow and > return are kind of obvious, but what about when a connection is idle but > under maintenance? Might be better to put the calls in > PoolableConnectionFactory's activate/passivate. > > 3) This raises the adjacent concern that it might be good to allow PCF > activate/passivate to be pluggable. > > 4) The spec has been around since 2017, but behaviors do not appear to > have been standardized. Making sure that what we do is safe for all > implementations may be tricky. > > Based on above, the following options seem reasonable and not too > difficult to me. > > a) do nothing > b) add a configuration property that makes dbcp send the messages on > activate/passivate or borrow/return (need to decide which) > After more research and listening to comments, I think this is the best approach, with beginRequest sent on PCF activate and endRequest sent on PCF passivate. Using activate/passivate instead of getConnection and close on the datasources enables us to make a single change and also prevents conflicts with pool maintenance (testWhileIdle). I would be happy to review a PR with tests for this if there are no objections. Phil > c) add another configuration property that tells PCF to let the driver > manage connection properties, so when used with b, fewer calls might be > needed to manage connection properties. > > Options b) and c) would have to consider potential conflicts with current > properties cacheState, enableAutoCommitOnReturn and rollbackOnReturn. > > Phil > > [1] https://issues.apache.org/jira/browse/DBCP-592 > [2] https://github.com/apache/commons-dbcp/pull/324 > > > > >
