This is an interesting quote cause i understand as it is implemented in
tomcat but also means any usage would potentially lead to deadlocks or
container integration to ensure thread safety is done right making in both
cases the spec unusable or hard to use from a user perspective. Should it
be pushed back to the spec?
Le 3 sept. 2016 18:28, "Mark Thomas" <ma...@apache.org> a écrit :
> On 02/09/2016 15:47, Romain Manni-Bucau wrote:
> > ~business code (simplified):
> >
> > public void myBusiness(AsyncResponse wrapperOfAsyncContext) {
> > new Thread() {
> > @Override
> > public void run() {
> > wrapperOfAsyncContext.synchronizedDispatch();
> > }
> > }.start();
> > wrapperOfAsyncContext.synchronizedMethod();
> > }
> >
> > If timing is good (and encountered enough to say it is in real life) then
> > both method call will lock cause:
> >
> > 1. for the user thread: the dispatch call will call
> pauseNonContainerThread
> > to wait the myBusiness thread to end (actually a bit more but you get the
> > idea)
> > 2. synchronizedMethod will lock on synchronizedDispatch
> >
> > so synchronizedMethod is lock on synchronizedDispatch which is lock on
> > the pauseNonContainerThread of the caller/http thread so both threads are
> > locked.
>
> Hmm.
>
> The relevant text from the Servlet spec is (for both dispatch() and
> complete()) is:
>
> "If any of the dispatch methods are called before the
> container-initiated dispatch that called startAsync has returned to the
> container, then the call will not take effect until after the
> container-initiated dispatch has returned to the container."
>
> The critical question is what does "...will not take effect until..." mean.
>
> Currently, Tomcat implements this as "...will block until...". I'll look
> into what it would take to implement this as "...note the request and
> execute it once...". Whether or not we change this will depend a lot on
> how complicated the change would be.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
