研磨Struts2 之 第十五章 防止重复提交【私塾在线原创】

所谓重复提交，就是用户在页面多次点击提交按钮，或者通过不断刷新页面，把已经提交过的数据多次向后台提交。

重复提交对于查询类的功能，问题还不是太大，但是对于新增或是修改类的功能，就有可能凭空的出现很多同样信息的重复数据，从而导致业务功能出现错误。

在Action中，让当前线程sleep了6秒钟，所以必须等6秒之后才能正确的结束调用。

如果这个时候用户乖乖的等足6秒，自然没有什么问题。但是，如果用户在第一次提交还没有响应的时候，又再次点击了提交按钮，则同样的请求再次被提交，这时候，如果不加任何控制的话，同样的请求就将被处理两次了。

Token也被称做令牌，所以使用标签防止重复提交，也常被称做使用令牌防止重复提交。

标签的使用非常简单，只需要在提交页面的标签内加上子标签就可以了。

如果把提交页面当做重复提交时返回的结果页面的话，通常还需要在这个页面上引用重复提交时的错误信息。重复提交的错误信息以动作错误信息的方式存在，所以我们只要用标签来引用即可。

使用标签，必须为Action引用名为token的预定义拦截器，它并不在defaultStack拦截器栈里，所以需要手动的引用token拦截器。

如果有重复提交的行为，Struts2将跳转到这个Action定义的名为invalid.token的Result。

 

 

回顾一下上面标签和token拦截器连用，解决了重复提交问题，用法极其简单：Action引用token拦截器，标签内加一个标签，两句话就足以概括，一分钟就足以做完。

但是结果稍稍有点遗憾：对于一次正常提交和一次重复提交，使用token拦截器会使得浏览器最终重定向到invalid.token指定的Result。那么，有没有更好的办法可以让“重复提交”看起来好像没有发生过，浏览器最终跳转到正常提交指定的Result呢？

当然有，而且做法同样简单，把token拦截器换为tokenSession拦截器即可。tokenSession拦截器与token拦截器唯一的不同是在判断某个请求为重复请求之后，并不是立即重定向到名为invalid.token的Result，而是先阻塞这个重复请求，直到浏览器响应最初的正常请求，然后就可以跳转到处理正常请求后的Result了。

 

视频配套PPT，视频地址【  研磨Struts2视频课程】

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26715408/viewspace-717300/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26715408/viewspace-717300/