This content has been marked as final.
Show 2 replies
-
1. Re: concurrent access to SFSB using SEAM Remoting
shane.bryzak Feb 23, 2007 7:59 PM (in response to zdaler)That's because the conversation is created in the first request, and if you delay the response then the remoting client won't know which conversation id was created. One alternative is to start your conversation when you first render the page and manually set the conversation id like this:
Seam.Remoting.getContext().setConversationId(#{conversationId});
That way the remoting calls will know which conversation context to use. -
2. Re: concurrent access to SFSB using SEAM Remoting
zdaler Feb 26, 2007 5:02 AM (in response to zdaler)Thanks for you answer.
Looking at the code inside the Conversation Manager we saw that if there is a concurrent call to a locked conversation context : a new temporary one is created :log.debug("No stored conversation, or concurrent call to the stored conversation"); initializeTemporaryConversation();
This lead to our problem since the concurrent-request-timeout is set to 1 sec by default. Setting this parameter to 20s did the trick : each request would wait enough time for the previous request to be completed.
in components.xml :<core:manager concurrent-request-timeout="20000" ...
Maybe you could add a note in section "3.1.10. Concurrency model" mentioning this parameter ...
In our case, it was really strange to have a new temporary (and empty !) conversation created to handle requests from a long running conversation ... maybe it solves some of your use-cases (?) ...