[weld-issues] [JBoss JIRA] Reopened: (WELD-865) Weld allows for concurrent call to conversation

[George Sapountzis (JIRA)]

     [ https://issues.jboss.org/browse/WELD-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Sapountzis reopened WELD-865:
------------------------------------



>From BusyConversationException javadoc:

Indicates that the container has rejected a request because a concurrent request is associated with the same conversation context.

The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type BusyConversationException from the restore view phase of the JSF lifecycle.

So I think that AbstractConversationContext.activate() should throw BusyConversationException which should caught, handled and re-thrown in WeldPhaseListener. Something like:

try
{
  conversationContext.activate(cid);
}
catch(BusyConversationException bce)
{
  conversationContext.deactivate(); // XXX what else here ?
  throw bce;
}
}

> Weld allows for concurrent call to conversation
> -----------------------------------------------
>
>                 Key: WELD-865
>                 URL: https://issues.jboss.org/browse/WELD-865
>             Project: Weld
>          Issue Type: Bug
>          Components: Scopes & Contexts, Web Tier integration (JSF, JSP, EL and Servlet) 
>    Affects Versions: 1.1.0.Final
>            Reporter: George Sapountzis
>            Assignee: Ales Justin
>             Fix For: 1.2.0.Beta1
>
>
> Concurrent calls to a @ConversationScoped component:
> Thread 1:
> AbstractConversationContext.activate(String cid)
> ConversationImpl.lock(long timeout) <-- returns true
> correctly proceed inside method
> Thread 2:
> AbstractConversationContext.activate(String cid)
> ConversationImpl.lock(long timeout) <-- returns false but activate() does not check result !!!
> *incorrectly* proceed inside method
> ----
> I think AbstractConversationContext.activate(String cid) should check the result of ConversationImpl.lock(long timeout) and not allow the second thread to proceed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira