Question about concurrent-request-timeout

ekusnitz Dec 26, 2006 12:02 PM

In working through the examples, I see that the concurrent-request-timeout appears to be extremely small -- at most, 50 seconds. So, for example, if you start up a couple of conversations, they will timeout very quickly.

My question is, is there a technical reason for this? Obviously, the longer you allow, the more likely you will run into optimistic locking conflicts, but are there any other issues?

1. Re: Question about concurrent-request-timeout

ekusnitz Dec 26, 2006 12:05 PM (in response to ekusnitz)

Oh, yes, and a related question is, there appears to be no notion of a converstation type. If I start a conversation in one bean and start another in a second bean, the next @End will complete the current conversation, regardless of which bean started it. Is that correct?
Actions
2. Re: Question about concurrent-request-timeout

norman.richards Dec 26, 2006 12:50 PM (in response to ekusnitz)

On the later question, yes. However, a conversation does have the concept of an intiator - the component that started the conversation. @Conversational components can declare that they are only allowed to take part in conversations that they initiate.

Conversations can also have ids, so you can specify things like "the conversation for editing product 25" and be able to enter that conversation as needed.
Actions
3. Re: Question about concurrent-request-timeout

norman.richards Dec 26, 2006 3:43 PM (in response to ekusnitz)

On the earlier question, concurrent request timeout is the timeout on concurrent requests in the same conversation. Seam serializes client requests in a session. If a second request comes in while another is still active, the request will block for concurrent-request-timeout ms.

The conversation-timeout is what determines the conversation timeout. It is a couple orders of magnitude larger.
Actions

Go to original post