ConversationEntry after @End method process is removed by endRequest[1] process and does not release lock. Therefore, when there is a request duplicate with the same Conversation ID by F5 operation etc, since a lock is not released, the request has to wait till the concurrent-request-timeout even if pre-request is already completed.
[1] org.jboss.seam.core.Manager.java
441: /** 442: * Touch the conversation stack, destroy ended conversations, 443: * and timeout inactive conversations. 444: */ 445: public void endRequest(Map<String, Object> session) 446: { 447: if ( isLongRunningConversation() ) 448: { 449: if ( log.isDebugEnabled() ) 450: { 451: log.debug("Storing conversation state: " + getCurrentConversationId()); 452: } 453: touchConversationStack( getCurrentConversationIdStack() ); 454: } 455: else 456: { 457: if ( log.isDebugEnabled() ) 458: { 459: log.debug("Discarding conversation state: " + getCurrentConversationId()); 460: } 461: //now safe to remove the entry => 462: removeCurrentConversationAndDestroyNestedContexts(session); 463: } 464: 465: /*if ( !Init.instance().isClientSideConversations() ) 466: {*/ 467: // difficult question: is it really safe to do this here? 468: // right now we do have to do it after committing the Seam 469: // transaction because we can't close EMs inside a txn 470: // (this might be a bug in HEM) 471: Manager.instance().conversationTimeout(session); 472: //} 473: }