serializing access to the same conversation

[asookazian]

I have seen this message so many times during Seam/RF development (and yes, as of RF 3.3.x there is the <a4j:queue/> to handle that globally or per form, etc.):

The conversation ended, timed out or was processing another request

Seam serializes access to the same conversation and will abort the request if it has to wait too long to get a lock on the conversation.

http://seamframework.org/Documentation/IGetTheConversationEndedTimedOutOrWasProcessingAnotherRequestWithAJAX

Does Weld have the same design in terms of serializing access to the same conversation like Seam?

[nickarls]

The spec says

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

I assume the same thing can be done with filters etc for other contexts in Seam 3

[asookazian]

I should have read the spec! (as usual)

But it sounds like it depends on the implementation of CDI b/c it's blocking or rejecting...

[nickarls]

When you do get around to reading the spec, you will find that after that sentence comes the conditions when it blocks and when it rejects ;-)

[matthijs]

Hmmm, when I read that part of the spec I also wondered when rejecting or when blocking will be chosen. But you (Nicklas) say that that is also written in the spec, right after that sentence.

In the final draft of the spec right after that sentence the spec begins a new chapter about the Conversation interface. Can you be more specific where the spec talks about blocking/rejecting conditions and what it says?

Greetings,

Matthijs

[nickarls]

Actually, I misread the spec ;-)

It doesn't say which but I would assume the most common approach (as in Weld) is to block for a configurable amount of time until giving up. Immediate reject can be considered a situation when block wait time is 0.