You can wrapped it in a singleton session bean with bean managed concurrency annotation and CDI in other session bean. Though the thread it created (or maybe there isn't any additional thread created, I am not sure) is not managed thread thus not suggested in EE environments.
Best Regards, Atkins > On Dec 9, 2014, at 12:16 AM, Pete Keyes <[email protected]> wrote: > > A singleton qualifies for concurrent execution by multiple threads in a > container unless it is write locked. > > Sent from my iPhone > >>> On Dec 8, 2014, at 5:01 AM, Oleg Kalnichevski <[email protected]> wrote: >>> >>> On Mon, 2014-12-08 at 14:31 +0200, Guri Livne wrote: >>> Just to make sure I understand: >>> You are saying " effectively renders PoolingHttpClientConnectionManager's >>> pooling capabilities almost useless." >>> >>> Because EJBs themselves are in a pool and the threads accessing those are >>> managed by the J2EE server (So no need to hold a pool per EJB instance), or >>> do you mean that the PoolingHttpClientConnectionManager itself invokes >>> threads and thus not suitable for EJB3.1 spec? >> >> Not, it does not spawn threads by itself. However, without concurrent >> request execution PoolingHttpClientConnectionManager has no real >> advantages over BasicHttpClientConnectionManager. >> >> Oleg >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
