On 6/18/15 8:17 AM, Oksana wrote: > 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.
Sorry for the slow response. You are correct that, as stated in the comment closing the original ticket, there is no direct way to limit the total number of pools. I can't think of a straightforward way to add that feature directly without significant performance impact, but that doesn't mean there is no way to do it. Feel free to either reopen the ticket or create a new one. Patches welcome, of course! Phil > > Thanks, > Oksana > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
