On 6/19/14, 2:36 PM, James Leskovar wrote: > Hi Phil, > > Thanks for the reply. I'll try my hand first at the Pair<Conn,Int> approach, > and if it looks workable I can open up a Jira issue.
Great! Feel free to ask questions if things don't fall into place easily. Phil > > Cheers, > James > > > -----Original Message----- > From: Phil Steitz [mailto:phil.ste...@gmail.com] > Sent: Thursday, 19 June 2014 12:24 PM > To: Commons Users List > Subject: Re: Multiplexed connections in commons pool > > On 6/18/14, 4:07 PM, James Leskovar wrote: >> Hi there, >> >> >> >> I have an application that needs to perform connection pooling, with >> the proviso that it's okay - and actually preferable - for more than >> one client to checkout and use the same connection object from the >> pool. Ideally, I would also like to limit the number of concurrent >> clients that are using a single connection object. I'm wondering what >> the best way to do this is. As a quick and dirty option, I suppose I >> could basically have my PooledObjectFactory return the same objects >> from makeObject(), and manually keep track of objects from inside my >> implementation. >> Thoughts? >> > This is an interesting use case that unfortunately is that easy to support in > [pool]. If you are interested in helping design and implement direct > support, please feel free to hop over to the dev list and open a JIRA. > > Your idea of just having the factory return identical instances won't work > because when clients return them, they will get exceptions because repeated > returns of the same object violates the > pool contract. You can make that approach work though by having > your factory source <Foo, int> pairs where Foo is what you want to pool. > Just make sure the FooInt instances are distinguishable by equals. > Unfortunately, your factory will have to maintain counters, which it can do > via the lifecycle methods and probably a hashmap keyed on the actual Foo > instances with rep counts as values. > > Phil >> >> >> Cheers, >> >> *James Leskovar* >> Software Engineer, Location Platforms >> >> TeleCommunication Systems, Inc. >> >> [ *Address* : TCS, iC Enterprise 1, Innovation Campus, Squires Way, >> Nth Wollongong, NSW, 2500, Australia ] [ *Tel* : +61 2 4221 2940 ] [ >> *Fax* : +61 2 4221 2901 ] [ *Email* : james.lesko...@telecomsys.com >> <mailto:james.lesko...@telecomsys.com> ] >> >> TCS <http://www.telecomsys.com/default.aspx>Facebook >> <https://www.facebook.com/pages/TCS/340389379402958>Twitter >> <https://twitter.com/TeleComSys>LinkedIn >> <http://www.linkedin.com/company/telecommunication-systems> >> >> >> >> CONFIDENTIALITY NOTICE: The information contained in this message may >> be privileged and/or confidential. If you are not the intended >> recipient, or responsible for delivering this message to the intended >> recipient, any review, forwarding, dissemination, distribution or >> copying of this communication or any attachment(s) is strictly >> prohibited. If you have received this message in error, please notify >> the sender immediately, and delete it and all attachments from your >> computer and network. >> > > --------------------------------------------------------------------- > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
