劳烦问下，kunson被封是什么情况？

kunson

李团长 发表于 2012-12-15 07:22
是啊，啥情况？
挺好一小伙儿，老爷们也喜欢http://ci.baidu.com/OxUvR2YsyK

团长，你那连接画的是啥？

send_linux

kunson 发表于 2012-12-15 15:03
谢谢大家的关心。哈哈。我回来了。昨天被封事发偶然，不过我觉得业务逻辑上有点问题。这是昨天被封后，我给 ...

谢谢反馈，这个机制是会改的，当时是为了应对垃圾信息发布者临时做的对策，如果没有垃圾信息的轰炸，我们会适时取消这个规则的

tom_xx_hu@yahoo

kunson 发表于 2012-12-15 15:03
谢谢大家的关心。哈哈。我回来了。昨天被封事发偶然，不过我觉得业务逻辑上有点问题。这是昨天被封后，我给 ...

如此说来，你自己至少有一半的责任。

聪明一点的软件设计，应该考虑到这是个分布式业务，容错传输延时和客户端系统延时，在前端得到后台的回应并且把回应呈现给用户之前，不激活“submit”功能。从concurrecy的角度，就是等待并呈送后台回应与“submit”，应当是mutual exclusive 操作，在一个client session中不允许它们并行。多数（好的）在线交易，都是这么做的。

但是，你是你口袋里钞票的主人，你要对它们负责任，无论在线交易系统是否包含这个确认——付款的互斥性，你都不会在页面僵持的时候重复点击“付款”，那样后果可能很严重的。

tom_xx_hu@yahoo

send_linux 发表于 2012-12-15 14:19
这个没啥神秘的哈，之前我们被大量的发垃圾广告的问题所干扰，他们的内容重复度很高，所以有了这个机制 ...

谢谢老大详解。
这应该是个纯技术问题，也应该（原则上）不难解决。大体上，在client session中，每次“递交”之后自动锁定“递交”功能，直到“确认递交”过程结束再释放，应该就可以了。

kunson

tom_xx_hu@yahoo 发表于 2012-12-15 23:23
如此说来，你自己至少有一半的责任。

聪明一点的软件设计，应该考虑到这是个分布式业务，容错传输延 ...

当时是点击了没有反应，我也没有留意浏览器的进度条，以为没点上，就又点了一次，还没反应，就继续乱点，自我进入逻辑混乱状态。。。

kunson

李团长 发表于 2012-12-16 00:19
回复 11# kunson

第二性征明显！