Hello, instead of the SFTP connections you can pool channels or sessions. Each of them will only have a single borrower, but multiple threads could use the same "physical" connection.
This is possible because ssh protocol allows some multiplexing. But in most scenarios I am not sure if the work is work it. BTW: I think unlike JCA wich allows a seperation between logical connections and managed connections the Pool does not offer a ready solution for that kind of abstraction (especially not related to tearing down all channels when one fails or initiating new physical connections starting with a given utilisation). Gruss Bernd BTW: something I would really like to see is a JDBC pool where you get connection stubs which get bound late to actual JDBC sessions. This helps code which holds on to the object and does not return it ASAP. Am Tue, 3 Feb 2015 18:28:01 -0500 schrieb James Carman <ja...@carmanconsulting.com>: > On Tue, Feb 3, 2015 at 5:07 PM, Matthew Huckaby > <matthew.huck...@gmail.com> wrote: > > > > JC> Perhaps you'd be more interested in a "cache" rather than a > > JC> "pool"? > > > > If the intention is to share an SFTP session/client reference > > between threads, check-in and check-out could be important. > > > > I was assuming that the true intent was to really share the instances > between threads. If that's the case, then a cache might be more > appropriate. However, as you point out, it's probably not wise to > share those connections with SFTP anyway, so pooling really is what > you want. You're going to have to do some form of serialization of > the messages/requests (whatever they're called) going across that > connection. May as well let commons-pool do it for you by > borrow/return pattern. > > --------------------------------------------------------------------- > 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
