On 09/28/2012 08:57 PM, Laird Nelson wrote:
> On Fri, Sep 28, 2012 at 11:41 AM, Ancoron Luciferis
> <ancoron.luciferis_at_googlemail.com
> <mailto:ancoron.luciferis_at_googlemail.com>> wrote:
>
> Well, that implementation is basically unnecessary and effectively
> the same as using your own EJB for doing the work.
>
> Unless I'm missing something, you would inject my EJB like this:
>
> @EJB
> private AbstractExecutorService aes;
>
>
> ...and then call any AbstractExecutorService method at all you want,
> including non-blocking ones (submit, for example, which doesn't block
> and doesn't itself create threads). All asynchrony proceeds through the
> EJB-permitted @Asynchronous method on my EJB, which in turn uses the
> GlassFish threadpool (or the WebLogic threadpool, or the JBoss
> threadpool, or whatever threadpool the EJB container has decided to
> stick behind their implementation of the @Asynchronous annotation) and
> which therefore is tunable via the application server's normal
> configuration options. I don't see how this is the same as doing new
> Thread(runnable).
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
As we don't know yet the real requirements of Nicolas' code I assumed
the worst case scenario, where he would need a real new thread for each
invocation.
I was not saying that your EJB-implementation is the same as "new
thread". Effectively, I was saying the exact opposite: Nicolas would be
able to implement a simple @Asynchronous method on some new EJB that in
turn invokes the relevant logic.
In case the logic he refers to uses ThreadLocal to e.g. determine a
state and do different things (e.g. in a recursive method invocation)
then using an EJB-implementation for this would definitively break the
logic unless the application logic takes care of all ThreadLocal-reset
stuff properly and guaranteed in any case (lots of try ... finally
probably). If he invokes logic external to him then it would probably
not be easy to change that.
In any case where Nicolas would have control over the code, he could
easily (I currently can't think of any use case that prevents that)
modify it so he don't need a separate thread for the logic, which would
be much better anyway (container-controlled thread scheduling = better
scalability = better performance).
On the other hand if he just wants to "fork away", then he could easily
use some @Asynchronous EJB method instead.
I don't see the need for an EJB-implementation of the ExecutorService,
unless he needs to plug it in somewhere that requires it to implement
that interface. In that case you are absolutely correct.
However, the question of the OP (or at least my understanding of it) led
me to assume another scenario.
Cheers,
Ancoron