为什么Seam对话id（cid）不按顺序排列
我在谈话中遇到了问题。
我知道当我在 URL 栏（http://myprojectname/login.xhtml?cid=1）中看到时，对话 id 按顺序工作。但在我的程序中，我首先开始对话，cid 为 1 (http://myprojectname/login.xhtml?cid=1)，然后我开始嵌套对话，cid 变为 4 (http://myprojectname/register.xhtml?cid =4）。为什么会发生这种情况？
在成功的程序中，cid 为 1，之后 cid 为 2，然后为新的嵌套对话为 3、4。但我们想知道为什么对话id变成1然后是4。
请解释一下。
I have a problem at seam conversation.
I know that conversation id works in sequencial order when i see at url bar (http://myprojectname/login.xhtml?cid=1). But in my program , I first begin conversation and cid is 1 (http://myprojectname/login.xhtml?cid=1) and then i begin nest conversation and cid becomes 4 (http://myprojectname/register.xhtml?cid=4). Why does it happen?
In successful program, cid is 1 after that cid is 2 and then 3, 4 for new nested conversation. But we wonder why conversation id becomes 1 and then 4.
Please explain me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的“问题”有不同的潜在原因。就您而言，我想，
cid=1和cid=2是临时对话，由登录重定向使用，cid=3很长-running 和cid=4是嵌套的。一般来说，URL 并不是跟踪对话使用/管理的最佳位置。 Seam 不会节省 cid，唯一可以保证的是 cid 总是会增长。
所以，我不会担心这个..
There are different potential causes of your "problem". In your case, I suppose,
cid=1andcid=2were temporary conversations, used by login-redirection,cid=3is long-running andcid=4is nested one.In general, urls are not the best place to track conversation usage/management. Seam doesn't economize on cid's, the only thing which is guaranteed is that cid's always grow.
So, I would not worry about that..