The strict "not allowed" rule of EJB3.1 was dropped in EJB3.2 specifically because the rule was essentially bogus.
By making it sound so ominous with "not allowed" and promised of broken Web Apps it made forced people to use servlets instead and for no "real" reason. Accordingly EJB3.2 allows WebApps to create and manage threads with no more than a simple "warning: do so wisely" which is always good advice ... :-) Sent from my iPhone > On Dec 11, 2014, at 6:35 PM, Shih-liang Chang <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
