Cameron, Scott <scott.cameron <at> sap.com> writes: > > > > Interesting that this has not come up before. You are right that PerUserPoolDataSource does not bound the > number of pools that can be created and SharedPoolDataSource does not bound the total combined size of the > keyed pool it maintains. Please do open a JIRA requesting the capability. > > > > An ugly but possibly adequate workaround would be to subclass either one of the datasources above and > override getPooledConnectionAndInfo to enforce a global bound that you maintain in a new instance > variable before calling the superclass method. > > Thanks for the confirmation of the issue. I've entered it into JIRA as DBCP-373. > > The ugly work-around you suggest is actually exactly what we ended up doing to > get access the inner object pool object. We're hoping we can replace it with > something nicer in the future but for now it does the trick with only a few > (admittedly stinky) lines of code. > > Cheers, > scott >
Hi, I was wondering if this issue was resolved. I can see that the JIRA request has been closed (https://issues.apache.org/jira/browse/DBCP- 373). However, I have looked into the source code changes (https://fisheye6.atlassian.com/changelog/commons?cs=1568055) and API documentation (version 2.0) and I don't see new attributes which would control the total number of user pools allocated by PerUserPoolDataSource. I am seeing a bunch of new attributes added to control the functionalities of individual pools, but I don't see any new options to control the total number of pools. Thanks, Oksana --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
