On Feb 1, 2013, at 1:31 AM, Bill Burke <bburke@...> wrote:
On 1/30/2013 4:24 PM, Marek Potociar wrote:
On Jan 30, 2013, at 8:54 PM, Bill Burke <bburke@...
On 1/30/2013 11:32 AM, Marek Potociar wrote:
I'm not sure I follow how the EJB async "fire-and-forget" nature
relates to HTTP.
Exactly my point, it doesn't relate, so you can't use it with JAX-RS.
The statement above a nice example of "non sequitur" fallacy IMO. One
can further expand the above ad absurdum by stating that thread pools do
not relate to HTTP, therefore you should not use thread pools with
JAX-RS, or when doing HTTP processing in general...
Actually re-read again what I typed. @Asynchronous + 'void' is
fire-and-forget. The expected behavior is no response. It is pretty much
similar to oneway in CORBA. HTTP requires a response. Why is that so hard
to grok here?
IMO, you're mixing "no response from processing" with "no response to HTTP request". IMO, a
processing facility can produce a response to a HTTP request as a side effect (by updating the state of the
AsyncResponse based on the processing outcome) and not produce any other intrinsic response at the same time. What
you are saying is that AsyncResponse should not even be used with Executors and Runnable tasks and that HTTP
response should not be returned from Runnable tasks, because these, too, are fire&forget. That's a nonsense.
Fire&forget tasks do have "side-effects". Otherwise they would be futile.
Although offloading is pointless without thread priorities, it is orthogonal.
fire-and-forget means no response. HTTP requires a response. I'll keep
repeating it until you get it....
Please, stop acting like you know it all and the rest of us just don't get
it. Do not assume that I'm not trying to see your point because I'm just too
stubborn to admit that I could be wrong. That's certainly not the case and I
hope I demonstrated it several times even in this forum. I truly disagree
with you in this case and repeating your mantra is not going to change it.
Mixing intrinsic response of a task with a HTTP response as a result of
updating input parameter state during the processing of the task is still a
mistake in my view.
Since there is no concept of thread priorities, the whole practice is
completely useless. You are better off delegating to an MDB or Executor,
which actually allows you to set priorities, manage flows, etc.
All and all, beyond it breaking the @Asynchronous contract, i don't want this
example in the spec because IMNSHO, it is an anti-pattern and encouraging
people to do things that they shouldn't.
Maybe that way we can close this down without heated debates about what's
right and wrong programming model for asynchronous EJBs. Why don't you come
up with a better sample that is in your view more appropriate for Java EE and
we can consider switching it?
[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Spec's reference of EJB's @Asynchronous is incorrect