Only reference about timeouts I have found is about non-concurrent timeouts. In Weld documentation there's this:

http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/

The container is permitted to destroy a conversation and all state held in its context at any time in order to conserve resources. A CDI implementation will normally do this on the basis of some kind of timeout—though this is not required by the specification. The timeout is the period of inactivity before the conversation is destroyed (as opposed to the amount of time the conversation is active).

The Conversation object provides a method to set the timeout. This is a hint to the container, which is free to ignore the setting.

conversation.setTimeout(timeoutInMillis);

Unfortunately this is not the timeout I want to change. That method or the parameter for @Begin gives only possibility to change the general timeout for single conversation, not concurrent-timeout. Is it so that Seam 2 provided more fine grained control via configuration even though clearly the implementation of Weld component would permit better control.

I found a mention of this in the documentation (lock timeouts):

The conversation context also offers a number of properties which control the behavior of conversation expiration (after this period of inactivity the conversation will be ended and destroyed by the containber), and the duration of lock timeouts (the conversation context ensures that a single thread is accessing any bean instances by locking access, if a lock can't be obtained after a certain time Weld will error rather than continue to wait for the lock). Additionally, you can alter the name of the parameter used to transfer the conversation id (by default, cid).

edit:

I think the following might provide what I need.

 @Inject BoundConversationContext conversationContext; 

BoundConversationContext provides a way to call setConcurrentAccessTimeout(10000) but even if it's done after a method annotated with @Begin, the value getConcurrentAccess gives for the second thread is 1000 (ten times lower). When should I set the value, and is it only for the current conversationContext? Maybe it is not thread-safe?

I did inject the ConversationContext, and called the setter but when the getter is called, the value is still the default.  Also the Conversation does not have the wanted method (setConcurrentTimeout). The documentation lacks a bit specifically on this point.

I try to debug this next Monday more but if you have any ideas, I would be grateful.