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

George Sapountzis (JIRA) jira-events at lists.jboss.org
Tue Mar 8 08:07:55 EST 2011

     [ 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:

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

More information about the weld-issues mailing list