问LCDS & Flex -防止注销后的DuplicateHTTPSession错误

EN

我有一个flex/LCDS堆栈，在这里我发现在注销之后，我经常(但不总是)开始在客户机上接收Duplicate HTTP Session错误。

下面是堆栈的重要事实：

• flex客户端在应用程序中具有登录/注销功能。页面在注销后不会刷新。(因此，Flex应用程序和底层的mx.messaging.FlexClient仍然是初始化的)
• 用户可以打开多个选项卡。
• per-client-authentication设置为false -我们正在尝试实现SSO (与JSession集成)，因此用户原则被绑定到JSession。
• 当使用长轮询进行消息传递以及打开两个(或更多)选项卡时，问题最为明显。
• 当使用RTMP或流通道时，这个问题很难再现。
• 用户绑定到JSession --也就是说，如果他们登录Tab1，他们就会登录到Tab2上。
• 当用户从任何一个选项卡中注销时，Jsession将失效。

这是我目前关于是什么引起这个问题的理论：

• Tab1 (T1)启动客户端->发布的ClientId1 (C1) -> JSession1 (J1)创建
• Tab2 (T2)启动客户端->发布的ClientId2 (C2) -> Joins J1
• T1日志在-> J1中不受影响
• T2日志在-> J1中不受影响
• T1和T2都订阅，开始在amflongpolling上进行轮询
• T1发送注销-> J1无效的-> J2
• T2发送投票(反对J1)
• T1注销完成，返回J2，更新cookie

最后两个调用会产生冲突，LCDS会看到FlexClient似乎与2 JSessions相关。

因此，会收到以下方面的错误：

Server.Processing.DuplicateSessionDetected检测到基于HTTP的重复FlexSessions，这通常是由于远程主机禁用会话cookie造成的.必须启用会话cookie才能正确管理客户端连接。

注意:我在一个独立的项目中重新创建了这个问题，我相信这不是我们的应用程序特定代码的问题，而是由状态/会话性质和共享同一个会话的多个选项卡之间的冲突引起的。

总之，我认为在服务器上会话由于来自一个选项卡的调用而失效，但在将响应发送到浏览器通知它新的JSession之前，会在旧的Jsession下发出调用。

对于这个重复的会话问题，有哪些适当的策略来防范？

更新

为了澄清，虽然场景类似于讨论过的这里，但存在细微的差异，这使得本文中的解决方案不合适。

具体来说，本文讨论通过使用JSP或编排的调用控制两个浏览器之间的JSessions初始创建来防止重复会话。

Flex实际上通过阻止出站RemoteObject调用来帮助这个过程，直到定义了本地FlexClient DSid变量，显示初始会话已经建立。

我的场景不同，因为JSession (&关联的LCDS FlexSession /客户端FlexClient对象)已经建立了一次(使用了本文中讨论的技术)，随后通过注销(这称为session.invalidate() )失效了JSession。

当Tab2发送带有过时JSession (重复的HTTP会话错误)的调用时，就会出现此问题。这种情况变得更加复杂，因为当LCDS抛出DuplicateHTTPSession错误时，它还会使与客户端附加的所有已知的JSession无效，这意味着Tab1 --以前还好--现在有了一个陈旧的JSession。下一次Tab1发送调用时，IT会导致DuplicateHTTPSession错误，循环会重复。

不幸的是，Flex框架挂钩用于在建立sesssions时延迟调用，在设置之后没有一种简单的方法(我已经发现)被重新启用。(我尝试了以下几点，但没有结果：)

 // Reset DSid to get a new FlexSession established on LCDS
   use namespace mx_internal

   public function resetFlexSession()
   {
        FlexClient.getInstance().id = null;  
        // Note - using FlexClient.NULL_ID also doesn't work.
   }