CN102761604A - 请求处理系统、请求处理方法和服务器 - Google Patents

Abstract

本发明提供一种请求处理系统、请求处理方法和服务器，请求处理系统包括：请求接收模块，在服务器端接收来自终端的请求；会话查找模块，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；处理控制模块，如果所述会话查找模块无法找到所述请求处理标志，则所述处理控制模块在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果所述会话查找模块找到了所述请求处理标志，则所述处理控制模块不对所述请求进行处理。通过本发明，允许用户通过不同的终端登录网页发送请求，并可以避免出现重复提交请求的问题，保证请求处理的准确性，不致造成数据的混乱。

Description

请求处理系统、请求处理方法和服务器

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种请求处理系统、一种请求处理方法和一种服务器。

背景技术

目前，在web应用系统的开发方面，比较常出现的是重复提交的问题，例如，用户通过页面登录网上商城的购物系统，如果因为用户快速频繁操作，就可能出现重复提交购物请求的情况，结果就造成购买过多商品造成经济损失的情况。

业界内，如果是基于JavaEE框架开发的web页面应用系统，其中使用的比较多的解决重复提交问题的方式，主要是通过在页面上设置一个令牌，然后，在后台的session会话中保存该令牌，然后，当用户第一次在该页面提交请求后，就清除会话中保存的该令牌，如果用户重复提交，服务器后台发现该令牌不存在，则可判断出重复提交了。

但是这种方式有个弊端，需要页面和后台都保存一个令牌，但是这种方式不利于服务器后台支持多终端的操作，比如用户同时使用手机、平板等、笔记本等同时登录页面发送请求的话，则实际上后台存在着多个会话，例如，用户通过手机发送请求、紧接着又通过平板发送请求的话，则后台删除对应两个会话中的令牌，却无法判断出重复请求，这必然导致另一请求无法正常处理，造成数据混乱。

因此，需要一种新的技术方案，允许用户通过不同的终端登录网页发送请求，并可以避免出现重复提交请求的问题，保证请求处理的准确性，不致造成数据的混乱。

发明内容

本发明所要解决的技术问题在于，提供一种新的技术方案，允许用户通过不同的终端登录网页发送请求，并可以避免出现重复提交请求的问题，保证请求处理的准确性，不致造成数据的混乱。

有鉴于此，本发明提供一种请求处理系统，包括：请求接收模块，在服务器端接收来自终端的请求；会话查找模块，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；处理控制模块，如果所述会话查找模块无法找到所述请求处理标志，则所述处理控制模块在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果所述会话查找模块找到了所述请求处理标志，则所述处理控制模块不对所述请求进行处理。在该技术方案中，通过检测session会话中的标志，不但可以保证同一终端的请求不会重复处理，也可以保证如果一个线程已经在处理请求时，不会存在另外线程正在处理其他终端的同样请求，最终保证了对请求的准确响应，不致数据换乱的情况。

在上述技术方案中，优选地，所述处理控制模块从所述服务器端调用用于处理所述请求的重入锁类型方法，对所述请求进行处理。在该技术方案中，基于现有的web应用系统开发技术，可以提供多种方式为来多线程的同步问题，例如，提供多个线程处理不同终端发出的同样请求，通过多个环境下实现的锁机制，都可以保证同一时间只有一个线程处理请求，本方案中，特别强调了JavaEE框架下的ReentrantLock重入锁，有助于很好实现本技术方案。

在上述技术方案中，优选地，还包括：方法判别模块，判断所述服务器端用于处理所述请求的方法是否为重入锁类型方法，并在判断结果为是时，启动所述会话查找模块和所述处理控制模块。在该技术方案中，由于对于某些请求，存在允许重复提交及处理的情况，对这类请求则不采用ReentrantLock方法进行处理，也不检测session会话中的标志，节省了不少操作，避免了服务器资源浪费。

在上述技术方案中，优选地，还包括：方法配置模块，在所述服务器端配置用于处理所述请求的重入锁类型方法。在该技术方案中，提供用户进行重入锁方法自定义的机制，可以保证用户随时对整个请求处理机制进行修改或修正。

在上述技术方案中，优选地，还包括：信息提示模块，从所述服务器端向所述终端发出提示信息，以提示与所述请求相同的另一请求正在被处理。在该技术方案中，在忽略掉用户重复提交的请求时，同时向用户发出通知，以及时提供反馈信息，可以采用输出string字符串的形式。

本发明还提供一种请求处理方法，包括：步骤202，在服务器端接收来自终端的请求；步骤204，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；步骤206，如果无法找到所述请求处理标志，则在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果找到了所述请求处理标志，则不对所述请求进行处理。在该技术方案中，通过检测session会话中的标志，不但可以保证同一终端的请求不会重复处理，也可以保证如果一个线程已经在处理请求时，不会存在另外线程正在处理其他终端的同样请求，最终保证了对请求的准确响应，不致数据换乱的情况。

在上述技术方案中，优选地，在所述步骤206中，对所述请求进行处理包括：从所述服务器端调用用于处理所述请求的重入锁类型方法，对所述请求进行处理。在该技术方案中，基于现有的web应用系统开发技术，可以提供多种方式为来多线程的同步问题，例如，提供多个线程处理不同终端发出的同样请求，通过多个环境下实现的锁机制，都可以保证同一时间只有一个线程处理请求，本方案中，特别强调了JavaEE框架下的ReentrantLock重入锁，有助于很好实现本技术方案。

在上述技术方案中，优选地，在所述步骤204之前，还包括：判断所述服务器端用于处理所述请求的方法是否为重入锁类型方法，并在判断结果为是时，进入所述步骤204。在该技术方案中，由于对于某些请求，存在允许重复提交及处理的情况，对这类请求则不采用ReentrantLock方法进行处理，也不检测session会话中的标志，节省了不少操作，避免了服务器资源浪费。

在上述技术方案中，优选地，在所述步骤204之前，还包括：在所述服务器端配置用于处理所述请求的重入锁类型方法。在该技术方案中，提供用户进行重入锁方法自定义的机制，可以保证用户随时对整个请求处理机制进行修改或修正。

在上述技术方案中，优选地，所述步骤206还包括：从所述服务器端向所述终端发出提示信息，以提示与所述请求相同的另一请求正在被处理。在该技术方案中，在忽略掉用户重复提交的请求时，同时向用户发出通知，以及时提供反馈信息，可以采用输出string字符串的形式。

本发明还提供一种服务器，包括：如上所述的请求处理系统。在该技术方案中，可以保证了对请求的准确响应，不致数据换乱的情况，进一步也就保证数据的安全稳定，由于服务器的其他处理功能的顺利展开。

通过以上技术方案，可以实现一种请求处理系统、一种请求处理方法和一种服务器，允许用户通过不同的终端登录网页发送请求，并可以避免出现重复提交请求的问题，保证请求处理的准确性，不致造成数据的混乱。

附图说明

图1是根据本发明的一个实施例的请求处理系统的框图；

图2是根据本发明的一个实施例的请求处理方法的流程图；

图3是根据本发明的一个实施例的服务器；

图4是根据本发明的一个实施例的请求处理系统的框图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1是根据本发明的一个实施例的请求处理系统的框图。

如图1所示，本发明提供一种请求处理系统100，包括：请求接收模块102，在服务器端接收来自终端的请求；会话查找模块104，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；处理控制模块106，如果所述会话查找模块104无法找到所述请求处理标志，则所述处理控制模块106在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果所述会话查找模块104找到了所述请求处理标志，则所述处理控制模块106不对所述请求进行处理。在该技术方案中，通过检测session会话中的标志，不但可以保证同一终端的请求不会重复处理，也可以保证如果一个线程已经在处理请求时，不会存在另外线程正在处理其他终端的同样请求，最终保证了对请求的准确响应，不致数据换乱的情况。

在上述技术方案中，所述处理控制模块106从所述服务器端调用用于处理所述请求的重入锁类型方法，对所述请求进行处理。在该技术方案中，基于现有的web应用系统开发技术，可以提供多种方式为来多线程的同步问题，例如，提供多个线程处理不同终端发出的同样请求，通过多个环境下实现的锁机制，都可以保证同一时间只有一个线程处理请求，本方案中，特别强调了JavaEE框架下的ReentrantLock重入锁，有助于很好实现本技术方案。

在上述技术方案中，还包括：方法判别模块108，判断所述服务器端用于处理所述请求的方法是否为重入锁类型方法，并在判断结果为是时，启动所述会话查找模块104和所述处理控制模块106。在该技术方案中，由于对于某些请求，存在允许重复提交及处理的情况，对这类请求则不采用ReentrantLock方法进行处理，也不检测session会话中的标志，节省了不少操作，避免了服务器资源浪费。

在上述技术方案中，还包括：方法配置模块110，在所述服务器端配置用于处理所述请求的重入锁类型方法。在该技术方案中，提供用户进行重入锁方法自定义的机制，可以保证用户随时对整个请求处理机制进行修改或修正。

在上述技术方案中，还包括：信息提示模块112，从所述服务器端向所述终端发出提示信息，以提示与所述请求相同的另一请求正在被处理。在该技术方案中，在忽略掉用户重复提交的请求时，同时向用户发出通知，以及时提供反馈信息，可以采用输出string字符串的形式。

图2是根据本发明的一个实施例的请求处理方法的流程图。

如图2所示，本发明还提供一种请求处理方法，包括：步骤202，在服务器端接收来自终端的请求；步骤204，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；步骤206，如果无法找到所述请求处理标志，则在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果找到了所述请求处理标志，则不对所述请求进行处理。在该技术方案中，通过检测session会话中的标志，不但可以保证同一终端的请求不会重复处理，也可以保证如果一个线程已经在处理请求时，不会存在另外线程正在处理其他终端的同样请求，最终保证了对请求的准确响应，不致数据换乱的情况。

在上述技术方案中，在所述步骤206中，对所述请求进行处理包括：从所述服务器端调用用于处理所述请求的重入锁类型方法，对所述请求进行处理。在该技术方案中，基于现有的web应用系统开发技术，可以提供多种方式为来多线程的同步问题，例如，提供多个线程处理不同终端发出的同样请求，通过多个环境下实现的锁机制，都可以保证同一时间只有一个线程处理请求，本方案中，特别强调了JavaEE框架下的ReentrantLock重入锁，有助于很好实现本技术方案。

在上述技术方案中，在所述步骤204之前，还包括：判断所述服务器端用于处理所述请求的方法是否为重入锁类型方法，并在判断结果为是时，进入所述步骤204。在该技术方案中，由于对于某些请求，存在允许重复提交及处理的情况，对这类请求则不采用ReentrantLock方法进行处理，也不检测session会话中的标志，节省了不少操作，避免了服务器资源浪费。

在上述技术方案中，在所述步骤204之前，还包括：在所述服务器端配置用于处理所述请求的重入锁类型方法。在该技术方案中，提供用户进行重入锁方法自定义的机制，可以保证用户随时对整个请求处理机制进行修改或修正。

在上述技术方案中，所述步骤206还包括：从所述服务器端向所述终端发出提示信息，以提示与所述请求相同的另一请求正在被处理。在该技术方案中，在忽略掉用户重复提交的请求时，同时向用户发出通知，以及时提供反馈信息，可以采用输出string字符串的形式。

图3是根据本发明的一个实施例的服务器。

如图3所示，本发明还提供一种服务器300，包括：如上所述的请求处理系统100。在该技术方案中，可以保证了对请求的准确响应，不致数据换乱的情况，进一步也就保证数据的安全稳定，由于服务器的其他处理功能的顺利展开。

以下详细说明本发明的技术方案中。

多线程进行数据处理时，很重要的一个问题就是数据同步（同一时间只能有一个线程使用数据对象）的问题，如果不解决好同步的问题，可能会引起数据的混乱，而且还有可能造成线程的死锁。在Java 5.0之前，用synchronized来解决这个问题，在Java 5.0中加入了一个新的类：ReentrantLock，也就是重入锁。

使用lock的基本形式是：

ReentrantLock的解释如下：

这个锁被称为Reentrant（重入）的原因是在一个线程中可以重复多次申请同一个锁，系统会保留加锁的次数，而在解锁的时候也就必须执行相同次数。

在一个线程已经得到锁可以执行程序的时候，可能会发现需要的条件还不能满足，这时他就必须等待直到条件满足。但是因为它已经对所需要操作的东西加了锁，其他的线程不能访问，因此它又可能会永远等待下去。现在可以用Condition条件对象来避免这种情况，具体方式可以例如：

sufficientFunds=bankLock.newCondition();

如果条件不满足，则可继续实现以下等待方式：

sufficientFunds.await();

这时线程就会释放锁并进入中断blocked状态，其他线程就有机会执行操作。当其他线程执行完后，就可通知等待的线程继续执行它的操作了，具体获取信号继续执行操作的方式：

sufficientFunds.signalAll();

当然也可以调用singal方法来获取信号，这样效率会高一些，但是有一定的危险性，因为它的唤醒具有随机性。

在申请锁的时候可以用tryLock方法，它会返回一个bool值来表示锁是否申请成功，如果没有成功，程序就可以做其他的事情了。

而在实际上，java.util.concurrent.locks包中提供了两种锁，一个就是ReentrantLock，另一个是ReentrantReadWriteLock，一般用于读操作远远多于写操作的时候：

p rivate ReentrantReadWriteLock rwl=new ReentrantReadWriteLock（）；

private Lock readLock=rwl.readLock();//读取数据，允许其他线程读取，但不允许写入

private Lock writeLock=rwl.writeLock();//写入数据，既不允许其他线程读取，也不允许其他进程写入

在Java 5.0之前，采用的是synchronized关键字来进行同步，但是和lock相比它有一些局限性：

1.申请锁的线程不能被interrupt中止，而tryLock、await方法都可以被interrupt中止的；

2.没有timeout超时设置；

3.只有一个隐性的condition条件。

基于上述比较，在本发明的一个实施例中，就是利用了ReentrantLock来处理请求。

本发明的目的主要是基于jdk1.5的线程同步锁和java ee编程中的session技术，解决web端用户重复提交，导致数据异常。

下面具体介绍如何使用ReentrantLock来实现来处理重复提交请求的问题，具体如下：

(1)首先，在编译类中声明锁：

private static Lock bankLock1=new ReentrantLock();

(2)获取当前登录用户的会话：

HttpSession session=ServletActionContext.getRequest().getSession();

(3)请求锁：

bankLock1.lock();此时，线程会堵塞，其他响应同样请求的线程不同使用bankLock1。

(4)从当前登录用户的会话中获取loginLock请求处理标志，如果有，则表示请求正在处理：

if(null!=session.getAttribute("loginLock")){

String as=“您的请求正在处理，请稍后！”；

(5)如果没有，则处理该请求，并将loginLock加入会话中：

else{session.setAttribute("loginLock","loginLock");}。

(6)请求处理完成，释放锁：

finally{

bankLock1.unlock();

}

基于上述的编码，本发明实施例可以实现一种请求处理系统，在该请求处理系统安装在服务器上，该服务器已经安装了JDK1.6，搭建好JavaEE的环境，并使用tomcat等web服务器进行部署web应用。

请求处理系统的结构可以如图4所示：

用户同时通过手机、笔记本、台式机等重复提交请求数据，同步组件402（相当于前述的请求接收模块）接收到用户的请求，并将请求放入请求队列中，此时，业务处理组件404（相当于前述的会话查找模块和处理控制模块）从请求队列中取出请求后，结合该请求对应的session会话中是否有标志loginLock，判断该请求是否重复提交，如果重复提交，则忽略处理该请求，并对用户进行提示，如果并非重复提交，则通过一个线程调用bankLock1方法处理该请求，此时其他线程不能调用bankLock1，同时在session会话中加入loginLock标志。

综上，通过本发明的技术方案，可以实现一种请求处理系统、一种请求处理方法和一种服务器，允许用户通过不同的终端登录网页发送请求，并可以避免出现重复提交请求的问题，保证请求处理的准确性，不致造成数据的混乱。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种请求处理系统，其特征在于，包括：

请求接收模块，在服务器端接收来自终端的请求；

会话查找模块，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；

处理控制模块，如果所述会话查找模块无法找到所述请求处理标志，则所述处理控制模块在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果所述会话查找模块找到了所述请求处理标志，则所述处理控制模块不对所述请求进行处理。

2.根据权利要求1所述的请求处理系统，其特征在于，所述处理控制模块从所述服务器端调用用于处理所述请求的重入锁类型方法，对所述请求进行处理。

3.根据权利要求1所述的请求处理系统，其特征在于，还包括：

方法判别模块，判断所述服务器端用于处理所述请求的方法是否为重入锁类型方法，并在判断结果为是时，启动所述会话查找模块和所述处理控制模块。

4.根据权利要求1所述的请求处理系统，其特征在于，还包括：

方法配置模块，在所述服务器端配置用于处理所述请求的重入锁类型方法。

5.根据权利要求1至4中任一项所述的请求处理系统，其特征在于，还包括：

信息提示模块，从所述服务器端向所述终端发出提示信息，以提示与所述请求相同的另一请求正在被处理。

6.一种请求处理方法，其特征在于，包括：

步骤202，在服务器端接收来自终端的请求；

步骤204，从所述服务器端的对应所述终端的会话中，查找与所述请求相对应的请求处理标志；

步骤206，如果无法找到所述请求处理标志，则在所述会话中添加所述请求处理标志，并对所述请求进行处理，且处理所述请求时不对其他终端发出的同样请求进行处理，如果找到了所述请求处理标志，则不对所述请求进行处理。

7.根据权利要求6所述的请求处理方法，其特征在于，在所述步骤206中，对所述请求进行处理包括：

从所述服务器端调用用于处理所述请求的重入锁类型方法，对所述请求进行处理。

8.根据权利要求7所述的请求处理方法，其特征在于，在所述步骤204之前，还包括：

判断所述服务器端用于处理所述请求的方法是否为重入锁类型方法，并在判断结果为是时，进入所述步骤204。

9.根据权利要求7所述的请求处理方法，其特征在于，在所述步骤204之前，还包括：

在所述服务器端配置用于处理所述请求的重入锁类型方法。

10.根据权利要求6至9中任一项所述的请求处理方法，其特征在于，所述步骤206还包括：

从所述服务器端向所述终端发出提示信息，以提示与所述请求相同的另一请求正在被处理。

11.一种服务器，其特征在于，包括：

根据权利要求1至5中任一项所述的请求处理系统。

Images