[seam-issues] [JBoss JIRA] (JBSEAM-5103) Conversation after @End method process does not release ConversationEntry lock
Marek Novotny (JIRA)
jira-events at lists.jboss.org
Mon May 27 04:55:06 EDT 2013
[ https://issues.jboss.org/browse/JBSEAM-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marek Novotny resolved JBSEAM-5103.
-----------------------------------
Resolution: Done
back ported the fix
> Conversation after @End method process does not release ConversationEntry lock
> ------------------------------------------------------------------------------
>
> Key: JBSEAM-5103
> URL: https://issues.jboss.org/browse/JBSEAM-5103
> Project: Seam 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.3.0.Final
> Reporter: Eiichi Nagai
> Assignee: Marek Novotny
> Fix For: 2.3.1.CR1
>
>
> 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.
> {code:title=[1] org.jboss.seam.core.Manager.java|borderStyle=solid}
> 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: }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the seam-issues
mailing list