应用系统数据库更新的方法和系统.pdf

上传人:小** 文档编号:4751878 上传时间:2018-11-05 格式:PDF 页数:14 大小:487.71KB
返回 下载 相关 举报
摘要
申请专利号:

CN201110409541.6

申请日:

2011.11.23

公开号:

CN103136308A

公开日:

2013.06.05

当前法律状态:

撤回

有效性:

无权

法律详情:

发明专利申请公布后的视为撤回IPC(主分类):G06F 17/30申请公布日:20130605|||实质审查的生效IPC(主分类):G06F 17/30申请日:20111123|||公开

IPC分类号:

G06F17/30

主分类号:

G06F17/30

申请人:

英业达股份有限公司

发明人:

杨卫华; 陈志丰

地址:

中国台湾台北市士林区后港街六十六号

优先权:

专利代理机构:

北京律诚同业知识产权代理有限公司 11006

代理人:

梁挥;常大军

PDF下载: PDF下载
内容摘要

本发明公开了一种应用系统数据库的更新方法和系统,包括注册模块,用于将一次应用会话过程中应用系统的请求方需要执行的多次数据库更新请求进行注册;记录模块,用于记录注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据;提交模块,在一次应用会话结束时提交多次数据库更新请求;合并模块,用于将多次数据库更新请求进行合并;以及更新模块,用于开启数据库事务并完成对应的数据库更新。本发明可以减少数据库访问次数,显著提高应用系统数据库的更新效率。

权利要求书

权利要求书一种应用系统数据库的更新方法,其特征在于,所述更新方法包括以下步骤:
a)在一次应用会话过程中,将应用系统的请求方需要执行的多次数据库更新请求进行注册;
b)记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据;
c)在一次应用会话结束时提交所述多次数据库更新请求;
d)将所述多次数据库更新请求进行合并;以及
e)开启数据库事务并完成对应的数据库更新。
如权利要求1所述的应用系统数据库的更新方法,其特征在于,请求方对数据库更新请求对应的变更数据进行记录。
如权利要求1或2所述的应用系统数据库的更新方法,其特征在于,请求方在同一次会话过程中需要使用此前已注册更新的同一笔数据时,从步骤b对应记录的变更数据中获取。
如权利要求1所述的应用系统数据库的更新方法,其特征在于,在存在对至少两个请求方分别进行数据库更新请求注册记录时,其中一个请求方在提交数据库更新请求时检查当前会话所需的数据库更新数据是否已被其他请求方的会话更改。
如权利要求1所述的应用系统数据库的更新方法,其特征在于,在存在对至少两个请求方分别进行数据库更新请求注册记录时,对所述至少两个请求方建立预先定义的数据更新顺序规则,以使得每个请求方在进行数据库更新之前,根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库发送更新请求。
如权利要求1所述的应用系统数据库的更新方法,其特征在于,所述步骤d还包括:在一次应用会话过程中请求方对同一笔数据的不同字段进行多次更新时,将针对所述同一笔数据的多次数据库更新请求合并为一次数据库更新请求。
一种应用系统数据库的更新系统,其特征在于,所述更新系统包括:
注册模块,所述注册模块用于将一次应用会话过程中应用系统的请求方需要执行的多次数据库更新请求进行注册,在同一次会话过程中需要使用此前已注册更新的同一笔数据时,从记录模块对应记录的变更数据中获取;
记录模块,所述记录模块用于记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据;
提交模块,所述提交模块在一次应用会话结束时提交所述多次数据库更新请求;
合并模块,所述合并模块用于将所述多次数据库更新请求进行合并,在一次应用会话过程中请求方对同一笔数据的不同字段进行多次更新时,将针对所述同一笔数据的多次数据库更新请求合并为一次数据库更新请求;以及
更新模块,所述更新模块用于开启数据库事务并完成对应的数据库更新。
如权利要求7所述的应用系统数据库的更新系统,其特征在于,注册模块对数据库更新请求对应的变更数据进行记录。
如权利要求7所述的应用系统数据库的更新系统,其特征在于,还包括检查模块,所述检查模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时,检查其中一个请求方在提交数据库更新请求时当前会话所需的数据库更新数据是否已被其他请求方的会话更改。
如权利要求7所述的应用系统数据库的更新系统,其特征在于,还包括规则建立模块,所述规则建立模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时,对所述至少两个请求方建立预先定义的数据更新顺序规则,以使得每个请求方在进行数据库更新之前,其对应的请求模块根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库发送更新请求。

说明书

说明书应用系统数据库更新的方法和系统
技术领域
本发明涉及服务器端请求方应用会话过程的效率提高技术,尤其涉及一种提高应用系统数据库更新效率的方法及系统。
背景技术
客户端程序在一次应用会话过程中,按业务处理的顺序在数据库事务范围内连续执行数据库读和写操作。
例如图1所示,请求方开始事务(步骤101)之后,按照业务处理顺序,依次向数据库写入数据A(步骤102),读出数据B(步骤103),写入数据C(步骤104),读出数据D(步骤105),更新数据E(步骤106),最后递交事务(步骤107)。
上述常规方法的多次数据库写入操作增加了数据库的访问次数,并且在并发事务中按照常规方法进行数据更新可能会导致死锁现象的出现。
例如图2所示,当存在两个请求方A和B同时向数据库应用会话事物时,由于请求方A中更新数据的顺序为先A后B,而同时请求方B中更新数据的顺序为先B后A,因此由于并发事务中数据更新的顺序不同导致上述类型的死锁。
发明内容
本发明的目的旨在至少解决现有技术中的上述问题之一。
为此,本发明的实施例提出一种可提高应用系统数据库的更新效率的方法及系统。
根据本发明的一个方面,本发明实施例提出了一种应用系统数据库的更新方法,所述更新方法包括以下步骤:
a)在一次应用会话过程中,将应用系统的请求方需要执行的多次数据库更新请求进行注册;
b)记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据;
c)在一次应用会话结束时提交所述多次数据库更新请求;
d)将所述多次数据库更新请求进行合并;以及
e)开启数据库事务并完成对应的数据库更新。
根据本发明进一步的实施例,请求方对数据库更新请求对应的变更数据进行记录。
根据本发明进一步的实施例,请求方在同一次会话过程中需要使用此前已注册更新的同一笔数据时,从步骤b对应记录的变更数据中获取。
根据本发明进一步的实施例,在存在对至少两个请求方分别进行数据库更新请求注册记录时,其中一个请求方在提交数据库更新请求时检查当前会话所需的数据库更新数据是否已被其他请求方的会话更改。
根据本发明进一步的实施例,在存在对至少两个请求方分别进行数据库更新请求注册记录时,对所述至少两个请求方建立预先定义的数据更新顺序规则,以使得每个请求方在进行数据库更新之前,根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库发送更新请求。
根据本发明进一步的实施例,步骤d还包括:在一次应用会话过程中请求方对同一笔数据的不同字段进行多次更新时,将针对所述同一笔数据的多次数据库更新请求合并为一次数据库更新请求。
根据本发明的另一方面,本发明的实施例提出一种应用系统数据库的更新系统,所述更新系统包括:注册模块,所述注册模块用于将一次应用会话过程中应用系统的请求方需要执行的多次数据库更新请求进行注册,在同一次会话过程中需要使用此前已注册更新的同一笔数据时,从记录模块对应记录的变更数据中获取;记录模块,所述记录模块用于记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据;提交模块,所述提交模块在一次应用会话结束时提交所述多次数据库更新请求;合并模块,所述合并模块用于将所述多次数据库更新请求进行合并,在一次应用会话过程中请求方对同一笔数据的不同字段进行多次更新时,将针对所述同一笔数据的多次数据库更新请求合并为一次数据库更新请求;以及更新模块,所述更新模块用于开启数据库事务并完成对应的数据库更新。
根据本发明进一步的实施例,注册模块对数据库更新请求对应的变更数据进行记录。
根据本发明进一步的实施例,注册模块在同一次会话过程中需要使用此前已注册更新的同一笔数据时,从记录模块对应记录的变更数据中获取。
根据本发明进一步的实施例,合并模块在一次应用会话过程中请求方对同一笔数据的不同字段进行多次更新时,将针对所述同一笔数据的多次数据库更新请求合并为一次数据库更新请求。
根据本发明进一步的实施例,更新系统还包括检查模块,所述检查模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时,检查其中一个请求方在提交数据库更新请求时当前会话所需的数据库更新数据是否已被其他请求方的会话更改。
根据本发明进一步的实施例,更新系统还包括规则建立模块,所述规则建立模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时,对所述至少两个请求方建立预先定义的数据更新顺序规则,以使得每个请求方在进行数据库更新之前,其对应的请求模块根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库发送更新请求。
本发明通过将多次数据库写入操作合并,从而减少数据库访问次数,并缩小数据库事务的跨度。因此,显著提高应用系统数据库的更新效率。
此外,在执行并行更新事务时,通过进一步建立数据更新顺序规则并根据规则对需要执行的更新请求进行排序,可便于管理数据库写入操作的执行顺序,从而避免不必要的死锁。
本发明附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到
以下结合附图和具体实施例对本发明进行详细描述,但不作为对本发明的限定。
附图说明
本发明的上述和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1为常规的应用系统数据库的更新方法流程图;
图2为利用常规的应用系统数据库的更新方法进行并发事务时出现的死锁现象流程;
图3为本发明实施例的应用系统数据库的更新系统结构方框图;
图4为本发明实施例的应用系统数据库的更新方法总体流程图;
图5为本发明应用系统数据库的更新方法的具体实施例流程图;
图6为利用本发明应用系统数据库的更新方法进行并发事务的具体实施例流程图。
具体实施方式
下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本发明,而不能解释为对本发明的限制。
请参考图3,该图显示了本发明实施例的应用系统数据库的更新系统结构方框图。
如图3所示,更新系统包括注册模块12、提交模块14、记录模块22、合并模块24和更新模块26。其中,注册模块12、提交模块14设置在请求方10一端,记录模块22、合并模块24和更新模块26设置在记录方20一端。这里,请求方10和记录方20是运行在服务器(server)端的应用,请求方10相当于在server端的客户端,记录方20相当于在server端的服务器端。
下面,将对该更新系统的工作原理做出详细说明。
请求方10对应包括的客户端程序,即注册模块12用于在一次应用会话过程中,将一次应用会话过程中应用系统的请求方10需要执行的多次数据库更新请求,向记录方20进行注册。
记录方20对应包括的记录模块22则用于记录注册模块12注册的多次数据库更新请求,同时记录请求对应的所有需要提交到数据库的变更数据。
提交模块14在一次应用会话结束时,向记录方20提交所述多次数据库更新请求,然后由合并模块24将提交的多次数据库更新请求进行合并。请求方10在一次应用会话过程中可能对同一笔数据库记录的不同字段进行多次更新。合并模块24识别这种针对同一记录的多次更新请求,并将其合并为一次数据库更新请求。然后,由更新模块26开启数据库事务并完成对应的数据库更新,最后提交事务。
这样,可以将多次数据库写入操作合并,减少数据库访问次数,并缩小数据库事务的跨度。
在一个实施例中,为保证数据一致性,注册模块12对数据库更新请求对应的变更数据进行记录。注册模块12在同一次会话过程中需要使用此前已注册更新的同一笔数据时,从记录模块22对应记录的变更数据中获取。
在一个实施例中,更新还包括检查模块(图中未显示),检查模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时,检查其中一个请求方在提交数据库更新请求时当前会话所需的数据库更新数据是否已被其他请求方的会话更改。如果所需更新数据在当前会话进行的过程中已被其它会话修改,则此次提交失败,需将此事务回滚。
在一个实施例中,更新系统还包括规则建立模块(图中未显示),规则建立模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时,对所述至少两个请求方建立预先定义的数据更新顺序规则,以使得每个请求方在进行数据库更新之前,其对应的请求模块根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库发送更新请求。从而,便于管理数据库写入操作的执行顺序,避免不必要的死锁。
下面参考图4,图4为本发明实施例的应用系统数据库的更新方法总体流程图。其中,该方法中提及的相同的名称定义可以参考上文。这里不再赘述。
首先,在一次应用会话过程中,将应用系统的请求方需要执行的多次数据库更新请求进行注册(步骤202);
然后,记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据(步骤204);
并且,在一次应用会话结束时提交所述多次数据库更新请求(步骤206);
接收到提交的更新请求后,将所述多次数据库更新请求进行合并(步骤208);
最后,开启数据库事务并完成对应的数据库更新(步骤210)。
现在,将结合图5的具体实施例对本发明应用系统数据库的更新方法原理给出详细说明。
如图5所知,在执行数据库写入操作时,请求方10向记录方20注册更新A(步骤301)、注册更新C(步骤303)和注册更新E(步骤305),由记录方20将请求方10注册的请求进行合并。而对于执行数据库读操作,请求方10则执行直接从数据库中获取数据B(步骤302)、获取数据D(步骤304)的读步骤。
并且,请求方10在应用会话末尾阶段,即请求方10在向记录方20发出最后一次读写操作请求之后发出提交请求(步骤306),以告诉记录方20这些数据要提交数据库。
记录方20将请求方10注册的请求进行合并,并且在接收到提交请求之后,开启数据库事务(步骤307),更新数据A、C、E,完成对应数据向数据库的写入(步骤308)。其中,请求方10在一次应用会话过程中可能对同一笔数据库记录的不同字段进行多次更新。记录方20识别这种针对同一记录的多次更新请求,并将其合并为一次数据库更新请求。
由图5可知,与常规更新方法相比,本发明引入了一个记录方,记录方负责记录所有需要提交到数据库的变更,当请求方需要更新一笔数据时,更新请求注册到记录方里进行记录,请求方尝试去数据库取数据。所有更新提交完毕之后,向记录方提交请求。由记录方将多次数据库更新请求进行合并,最后时间点打开事务,提交事务。
为保证数据一致性,应用该方法时应注意以下问题:
请求方:
请求方需要记录已经向记录方注册的数据变更,当请求方同一次会话过程中需要使用此前已向记录方注册变更的同一笔数据,应使用缓存于记录方中的数据而不是重新从数据库中获取。例如请求方从数据库中获取数据A,将数据A修改为A’,并将此修改注册到记录方中,同时请求方需要保留数据A’,如果请求方在同一会话的后续处理中需要再次使用数据A,此时清求方不应再从数据库中重新获取该数据,而应该使用保留在请求方中的A’。
记录方:
记录方在将数据变更提交到数据库的过程中应采用乐观锁机制(Optimistic Locking),即在存在对至少两个请求方分别进行数据库更新请求注册记录时,更新数据时需检查所需更新的记录是否已被其它记录方实例更改,如果所需更新数据在当前会话进行的过程中已被其它会话修改,则此次提交失败,需将此事务回滚。
在存在对至少两个请求方分别进行数据库更新请求注册记录的并发事务时,可以对所述至少两个请求方建立预先定义的数据更新顺序规则,以使得每个请求方在进行数据库更新之前,根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库发送更新请求。以便于管理数据库写入操作的执行顺序,避免不必要的死锁。
对于死锁的改善可以结合图6的实施例进行说明,图6为利用本发明应用系统数据库的更新方法进行并发事务的具体实施例流程图。
请求方1 100和请求方2 100’均需要在一次应用会话中项数据库执行数据A、B、C的写入操作,仅数据更新的顺序不同。
如图6所示,对于请求方1 100和请求方2 100’分别对应引入记录方1 200和记录方2 200’。
其中请求方1 100首先通过步骤401、402和403向记录方1 200注册更新数据A、C和B,并在最后一次会话结束时提交请求(步骤404)。然后,记录方1 200在向数据库更新数据前,先读取预先定义的数据更新顺序规则(update order rule data),根据规则对需要执行的更新请求进行排序(步骤405),再依序向数据库发出更新请求,开始事务1(步骤406)。接着执行步骤407、408和409,向数据库更新事务,最后提交事务1(步骤410)。
同样地,请求方2 100’首先通过步骤501、502和503向记录方2 200’注册更新数据B、A和C,并在最后一次会话结束时提交请求(步骤504)。然后,记录方2 200,在向数据库更新数据前,读取预先定义的数据更新顺序规则,根据规则对需要执行的更新请求进行排序(步骤505),再依序向数据库发出更新请求,开始事务2(步骤506)。接着执行步骤507、508和509,向数据库更新事务,最后提交事务2(步骤510)。
如图6所示,当事务2更新表A中的记录A1时,首先需要获取排他锁,当事务1尝试更新同一笔记录时,由于该数据已被事务2锁定,需要等待事务2提交后,表A上的排他锁释放,事务1才能开始对表A进行更新。因此,当系统中所有数据更新都依照预先定义的顺序规则进行,就可以有效避免前述死锁情况。
本发明通过将多次数据库写入操作合并,从而减少数据库访问次数,并缩小数据库事务的跨度。因此,显著提高应用系统数据库的更新效率。
在执行并行更新事务时,通过进一步建立数据更新顺序规则并根据规则对需要执行的更新请求进行排序,可便于管理数据库写入操作的执行顺序,从而避免不必要的死锁。
当然,本发明还可有其它多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

应用系统数据库更新的方法和系统.pdf_第1页
第1页 / 共14页
应用系统数据库更新的方法和系统.pdf_第2页
第2页 / 共14页
应用系统数据库更新的方法和系统.pdf_第3页
第3页 / 共14页
点击查看更多>>
资源描述

《应用系统数据库更新的方法和系统.pdf》由会员分享,可在线阅读,更多相关《应用系统数据库更新的方法和系统.pdf(14页珍藏版)》请在专利查询网上搜索。

1、(10)申请公布号 CN 103136308 A (43)申请公布日 2013.06.05 CN 103136308 A *CN103136308A* (21)申请号 201110409541.6 (22)申请日 2011.11.23 G06F 17/30(2006.01) (71)申请人 英业达股份有限公司 地址 中国台湾台北市士林区后港街六十六 号 (72)发明人 杨卫华 陈志丰 (74)专利代理机构 北京律诚同业知识产权代理 有限公司 11006 代理人 梁挥 常大军 (54) 发明名称 应用系统数据库更新的方法和系统 (57) 摘要 本发明公开了一种应用系统数据库的更新方 法和系统, 。

2、包括注册模块, 用于将一次应用会话过 程中应用系统的请求方需要执行的多次数据库更 新请求进行注册 ; 记录模块, 用于记录注册的多 次数据库更新请求及对应的所有需要提交到数据 库的变更数据 ; 提交模块, 在一次应用会话结束 时提交多次数据库更新请求 ; 合并模块, 用于将 多次数据库更新请求进行合并 ; 以及更新模块, 用于开启数据库事务并完成对应的数据库更新。 本发明可以减少数据库访问次数, 显著提高应用 系统数据库的更新效率。 (51)Int.Cl. 权利要求书 2 页 说明书 6 页 附图 5 页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书2页 说明书6页 。

3、附图5页 (10)申请公布号 CN 103136308 A CN 103136308 A *CN103136308A* 1/2 页 2 1. 一种应用系统数据库的更新方法, 其特征在于, 所述更新方法包括以下步骤 : a) 在一次应用会话过程中, 将应用系统的请求方需要执行的多次数据库更新请求进行 注册 ; b) 记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数 据 ; c) 在一次应用会话结束时提交所述多次数据库更新请求 ; d) 将所述多次数据库更新请求进行合并 ; 以及 e) 开启数据库事务并完成对应的数据库更新。 2. 如权利要求 1 所述的应用系统数据库的更新方法。

4、, 其特征在于, 请求方对数据库更 新请求对应的变更数据进行记录。 3.如权利要求1或2所述的应用系统数据库的更新方法, 其特征在于, 请求方在同一次 会话过程中需要使用此前已注册更新的同一笔数据时, 从步骤 b 对应记录的变更数据中获 取。 4. 如权利要求 1 所述的应用系统数据库的更新方法, 其特征在于, 在存在对至少两个 请求方分别进行数据库更新请求注册记录时, 其中一个请求方在提交数据库更新请求时检 查当前会话所需的数据库更新数据是否已被其他请求方的会话更改。 5. 如权利要求 1 所述的应用系统数据库的更新方法, 其特征在于, 在存在对至少两个 请求方分别进行数据库更新请求注册记录。

5、时, 对所述至少两个请求方建立预先定义的数据 更新顺序规则, 以使得每个请求方在进行数据库更新之前, 根据所述规则对需要执行的数 据库更新请求进行排序和依照所述排序向数据库发送更新请求。 6. 如权利要求 1 所述的应用系统数据库的更新方法, 其特征在于, 所述步骤 d 还包括 : 在一次应用会话过程中请求方对同一笔数据的不同字段进行多次更新时, 将针对所述同一 笔数据的多次数据库更新请求合并为一次数据库更新请求。 7. 一种应用系统数据库的更新系统, 其特征在于, 所述更新系统包括 : 注册模块, 所述注册模块用于将一次应用会话过程中应用系统的请求方需要执行的多 次数据库更新请求进行注册, 。

6、在同一次会话过程中需要使用此前已注册更新的同一笔数据 时, 从记录模块对应记录的变更数据中获取 ; 记录模块, 所述记录模块用于记录所述注册的多次数据库更新请求及对应的所有需要 提交到数据库的变更数据 ; 提交模块, 所述提交模块在一次应用会话结束时提交所述多次数据库更新请求 ; 合并模块, 所述合并模块用于将所述多次数据库更新请求进行合并, 在一次应用会话 过程中请求方对同一笔数据的不同字段进行多次更新时, 将针对所述同一笔数据的多次数 据库更新请求合并为一次数据库更新请求 ; 以及 更新模块, 所述更新模块用于开启数据库事务并完成对应的数据库更新。 8. 如权利要求 7 所述的应用系统数据。

7、库的更新系统, 其特征在于, 注册模块对数据库 更新请求对应的变更数据进行记录。 9. 如权利要求 7 所述的应用系统数据库的更新系统, 其特征在于, 还包括检查模块, 所 述检查模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录时, 检查其中 一个请求方在提交数据库更新请求时当前会话所需的数据库更新数据是否已被其他请求 权 利 要 求 书 CN 103136308 A 2 2/2 页 3 方的会话更改。 10. 如权利要求 7 所述的应用系统数据库的更新系统, 其特征在于, 还包括规则建立 模块, 所述规则建立模块用于在存在对至少两个请求方分别进行数据库更新请求注册记录 时, 对所。

8、述至少两个请求方建立预先定义的数据更新顺序规则, 以使得每个请求方在进行 数据库更新之前, 其对应的请求模块根据所述规则对需要执行的数据库更新请求进行排序 和依照所述排序向数据库发送更新请求。 权 利 要 求 书 CN 103136308 A 3 1/6 页 4 应用系统数据库更新的方法和系统 技术领域 0001 本发明涉及服务器端请求方应用会话过程的效率提高技术, 尤其涉及一种提高应 用系统数据库更新效率的方法及系统。 背景技术 0002 客户端程序在一次应用会话过程中, 按业务处理的顺序在数据库事务范围内连续 执行数据库读和写操作。 0003 例如图 1 所示, 请求方开始事务 ( 步骤 。

9、101) 之后, 按照业务处理顺序, 依次向数据 库写入数据 A( 步骤 102), 读出数据 B( 步骤 103), 写入数据 C( 步骤 104), 读出数据 D( 步骤 105), 更新数据 E( 步骤 106), 最后递交事务 ( 步骤 107)。 0004 上述常规方法的多次数据库写入操作增加了数据库的访问次数, 并且在并发事务 中按照常规方法进行数据更新可能会导致死锁现象的出现。 0005 例如图 2 所示, 当存在两个请求方 A 和 B 同时向数据库应用会话事物时, 由于请求 方 A 中更新数据的顺序为先 A 后 B, 而同时请求方 B 中更新数据的顺序为先 B 后 A, 因此由。

10、 于并发事务中数据更新的顺序不同导致上述类型的死锁。 发明内容 0006 本发明的目的旨在至少解决现有技术中的上述问题之一。 0007 为此, 本发明的实施例提出一种可提高应用系统数据库的更新效率的方法及系 统。 0008 根据本发明的一个方面, 本发明实施例提出了一种应用系统数据库的更新方法, 所述更新方法包括以下步骤 : 0009 a) 在一次应用会话过程中, 将应用系统的请求方需要执行的多次数据库更新请求 进行注册 ; 0010 b) 记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更 数据 ; 0011 c) 在一次应用会话结束时提交所述多次数据库更新请求 ; 0012。

11、 d) 将所述多次数据库更新请求进行合并 ; 以及 0013 e) 开启数据库事务并完成对应的数据库更新。 0014 根据本发明进一步的实施例, 请求方对数据库更新请求对应的变更数据进行记 录。 0015 根据本发明进一步的实施例, 请求方在同一次会话过程中需要使用此前已注册更 新的同一笔数据时, 从步骤 b 对应记录的变更数据中获取。 0016 根据本发明进一步的实施例, 在存在对至少两个请求方分别进行数据库更新请求 注册记录时, 其中一个请求方在提交数据库更新请求时检查当前会话所需的数据库更新数 据是否已被其他请求方的会话更改。 说 明 书 CN 103136308 A 4 2/6 页 5。

12、 0017 根据本发明进一步的实施例, 在存在对至少两个请求方分别进行数据库更新请求 注册记录时, 对所述至少两个请求方建立预先定义的数据更新顺序规则, 以使得每个请求 方在进行数据库更新之前, 根据所述规则对需要执行的数据库更新请求进行排序和依照所 述排序向数据库发送更新请求。 0018 根据本发明进一步的实施例, 步骤 d 还包括 : 在一次应用会话过程中请求方对同 一笔数据的不同字段进行多次更新时, 将针对所述同一笔数据的多次数据库更新请求合并 为一次数据库更新请求。 0019 根据本发明的另一方面, 本发明的实施例提出一种应用系统数据库的更新系统, 所述更新系统包括 : 注册模块, 所。

13、述注册模块用于将一次应用会话过程中应用系统的请求 方需要执行的多次数据库更新请求进行注册, 在同一次会话过程中需要使用此前已注册更 新的同一笔数据时, 从记录模块对应记录的变更数据中获取 ; 记录模块, 所述记录模块用于 记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变更数据 ; 提交模 块, 所述提交模块在一次应用会话结束时提交所述多次数据库更新请求 ; 合并模块, 所述合 并模块用于将所述多次数据库更新请求进行合并, 在一次应用会话过程中请求方对同一笔 数据的不同字段进行多次更新时, 将针对所述同一笔数据的多次数据库更新请求合并为一 次数据库更新请求 ; 以及更新模块, 所。

14、述更新模块用于开启数据库事务并完成对应的数据 库更新。 0020 根据本发明进一步的实施例, 注册模块对数据库更新请求对应的变更数据进行记 录。 0021 根据本发明进一步的实施例, 注册模块在同一次会话过程中需要使用此前已注册 更新的同一笔数据时, 从记录模块对应记录的变更数据中获取。 0022 根据本发明进一步的实施例, 合并模块在一次应用会话过程中请求方对同一笔数 据的不同字段进行多次更新时, 将针对所述同一笔数据的多次数据库更新请求合并为一次 数据库更新请求。 0023 根据本发明进一步的实施例, 更新系统还包括检查模块, 所述检查模块用于在存 在对至少两个请求方分别进行数据库更新请求。

15、注册记录时, 检查其中一个请求方在提交数 据库更新请求时当前会话所需的数据库更新数据是否已被其他请求方的会话更改。 0024 根据本发明进一步的实施例, 更新系统还包括规则建立模块, 所述规则建立模块 用于在存在对至少两个请求方分别进行数据库更新请求注册记录时, 对所述至少两个请求 方建立预先定义的数据更新顺序规则, 以使得每个请求方在进行数据库更新之前, 其对应 的请求模块根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据 库发送更新请求。 0025 本发明通过将多次数据库写入操作合并, 从而减少数据库访问次数, 并缩小数据 库事务的跨度。因此, 显著提高应用系统数据库的更新。

16、效率。 0026 此外, 在执行并行更新事务时, 通过进一步建立数据更新顺序规则并根据规则对 需要执行的更新请求进行排序, 可便于管理数据库写入操作的执行顺序, 从而避免不必要 的死锁。 0027 本发明附加的方面和优点将在下面的描述中部分给出, 部分将从下面的描述中变 得明显, 或通过本发明的实践了解到 说 明 书 CN 103136308 A 5 3/6 页 6 0028 以下结合附图和具体实施例对本发明进行详细描述, 但不作为对本发明的限定。 附图说明 0029 本发明的上述和 / 或附加的方面和优点从下面结合附图对实施例的描述中将变 得明显和容易理解, 其中 : 0030 图 1 为常。

17、规的应用系统数据库的更新方法流程图 ; 0031 图 2 为利用常规的应用系统数据库的更新方法进行并发事务时出现的死锁现象 流程 ; 0032 图 3 为本发明实施例的应用系统数据库的更新系统结构方框图 ; 0033 图 4 为本发明实施例的应用系统数据库的更新方法总体流程图 ; 0034 图 5 为本发明应用系统数据库的更新方法的具体实施例流程图 ; 0035 图 6 为利用本发明应用系统数据库的更新方法进行并发事务的具体实施例流程 图。 具体实施方式 0036 下面详细描述本发明的实施例, 所述实施例的示例在附图中示出, 其中自始至终 相同或类似的标号表示相同或类似的元件或具有相同或类似功。

18、能的元件。 下面通过参考附 图描述的实施例是示例性的, 仅用于解释本发明, 而不能解释为对本发明的限制。 0037 请参考图 3, 该图显示了本发明实施例的应用系统数据库的更新系统结构方框图。 0038 如图3所示, 更新系统包括注册模块12、 提交模块14、 记录模块22、 合并模块24和 更新模块 26。其中, 注册模块 12、 提交模块 14 设置在请求方 10 一端, 记录模块 22、 合并模 块 24 和更新模块 26 设置在记录方 20 一端。这里, 请求方 10 和记录方 20 是运行在服务器 (server)端的应用, 请求方10相当于在server端的客户端, 记录方20相当。

19、于在server端 的服务器端。 0039 下面, 将对该更新系统的工作原理做出详细说明。 0040 请求方10对应包括的客户端程序, 即注册模块12用于在一次应用会话过程中, 将 一次应用会话过程中应用系统的请求方 10 需要执行的多次数据库更新请求, 向记录方 20 进行注册。 0041 记录方 20 对应包括的记录模块 22 则用于记录注册模块 12 注册的多次数据库更 新请求, 同时记录请求对应的所有需要提交到数据库的变更数据。 0042 提交模块14在一次应用会话结束时, 向记录方20提交所述多次数据库更新请求, 然后由合并模块 24 将提交的多次数据库更新请求进行合并。请求方 10。

20、 在一次应用会话过 程中可能对同一笔数据库记录的不同字段进行多次更新。合并模块 24 识别这种针对同一 记录的多次更新请求, 并将其合并为一次数据库更新请求。然后, 由更新模块 26 开启数据 库事务并完成对应的数据库更新, 最后提交事务。 0043 这样, 可以将多次数据库写入操作合并, 减少数据库访问次数, 并缩小数据库事务 的跨度。 0044 在一个实施例中, 为保证数据一致性, 注册模块 12 对数据库更新请求对应的变更 数据进行记录。注册模块 12 在同一次会话过程中需要使用此前已注册更新的同一笔数据 说 明 书 CN 103136308 A 6 4/6 页 7 时, 从记录模块 2。

21、2 对应记录的变更数据中获取。 0045 在一个实施例中, 更新还包括检查模块 ( 图中未显示 ), 检查模块用于在存在对至 少两个请求方分别进行数据库更新请求注册记录时, 检查其中一个请求方在提交数据库更 新请求时当前会话所需的数据库更新数据是否已被其他请求方的会话更改。 如果所需更新 数据在当前会话进行的过程中已被其它会话修改, 则此次提交失败, 需将此事务回滚。 0046 在一个实施例中, 更新系统还包括规则建立模块 ( 图中未显示 ), 规则建立模块用 于在存在对至少两个请求方分别进行数据库更新请求注册记录时, 对所述至少两个请求方 建立预先定义的数据更新顺序规则, 以使得每个请求方在。

22、进行数据库更新之前, 其对应的 请求模块根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据库 发送更新请求。从而, 便于管理数据库写入操作的执行顺序, 避免不必要的死锁。 0047 下面参考图4, 图4为本发明实施例的应用系统数据库的更新方法总体流程图。 其 中, 该方法中提及的相同的名称定义可以参考上文。这里不再赘述。 0048 首先, 在一次应用会话过程中, 将应用系统的请求方需要执行的多次数据库更新 请求进行注册 ( 步骤 202) ; 0049 然后, 记录所述注册的多次数据库更新请求及对应的所有需要提交到数据库的变 更数据 ( 步骤 204) ; 0050 并且, 在。

23、一次应用会话结束时提交所述多次数据库更新请求 ( 步骤 206) ; 0051 接收到提交的更新请求后, 将所述多次数据库更新请求进行合并 ( 步骤 208) ; 0052 最后, 开启数据库事务并完成对应的数据库更新 ( 步骤 210)。 0053 现在, 将结合图 5 的具体实施例对本发明应用系统数据库的更新方法原理给出详 细说明。 0054 如图 5 所知, 在执行数据库写入操作时, 请求方 10 向记录方 20 注册更新 A( 步骤 301)、 注册更新 C( 步骤 303) 和注册更新 E( 步骤 305), 由记录方 20 将请求方 10 注册的请 求进行合并。而对于执行数据库读操。

24、作, 请求方 10 则执行直接从数据库中获取数据 B( 步 骤 302)、 获取数据 D( 步骤 304) 的读步骤。 0055 并且, 请求方 10 在应用会话末尾阶段, 即请求方 10 在向记录方 20 发出最后一次 读写操作请求之后发出提交请求 ( 步骤 306), 以告诉记录方 20 这些数据要提交数据库。 0056 记录方20将请求方10注册的请求进行合并, 并且在接收到提交请求之后, 开启数 据库事务 ( 步骤 307), 更新数据 A、 C、 E, 完成对应数据向数据库的写入 ( 步骤 308)。其中, 请求方 10 在一次应用会话过程中可能对同一笔数据库记录的不同字段进行多次更。

25、新。记 录方 20 识别这种针对同一记录的多次更新请求, 并将其合并为一次数据库更新请求。 0057 由图 5 可知, 与常规更新方法相比, 本发明引入了一个记录方, 记录方负责记录所 有需要提交到数据库的变更, 当请求方需要更新一笔数据时, 更新请求注册到记录方里进 行记录, 请求方尝试去数据库取数据。所有更新提交完毕之后, 向记录方提交请求。由记录 方将多次数据库更新请求进行合并, 最后时间点打开事务, 提交事务。 0058 为保证数据一致性, 应用该方法时应注意以下问题 : 0059 请求方 : 0060 请求方需要记录已经向记录方注册的数据变更, 当请求方同一次会话过程中需要 使用此前。

26、已向记录方注册变更的同一笔数据, 应使用缓存于记录方中的数据而不是重新从 说 明 书 CN 103136308 A 7 5/6 页 8 数据库中获取。例如请求方从数据库中获取数据 A, 将数据 A 修改为 A , 并将此修改注册 到记录方中, 同时请求方需要保留数据 A , 如果请求方在同一会话的后续处理中需要再次 使用数据 A, 此时清求方不应再从数据库中重新获取该数据, 而应该使用保留在请求方中的 A 。 0061 记录方 : 0062 记录方在将数据变更提交到数据库的过程中应采用乐观锁机制 (Optimistic Locking), 即在存在对至少两个请求方分别进行数据库更新请求注册记录。

27、时, 更新数据时 需检查所需更新的记录是否已被其它记录方实例更改, 如果所需更新数据在当前会话进行 的过程中已被其它会话修改, 则此次提交失败, 需将此事务回滚。 0063 在存在对至少两个请求方分别进行数据库更新请求注册记录的并发事务时, 可以 对所述至少两个请求方建立预先定义的数据更新顺序规则, 以使得每个请求方在进行数据 库更新之前, 根据所述规则对需要执行的数据库更新请求进行排序和依照所述排序向数据 库发送更新请求。以便于管理数据库写入操作的执行顺序, 避免不必要的死锁。 0064 对于死锁的改善可以结合图 6 的实施例进行说明, 图 6 为利用本发明应用系统数 据库的更新方法进行并发。

28、事务的具体实施例流程图。 0065 请求方 1 100 和请求方 2 100 均需要在一次应用会话中项数据库执行数据 A、 B、 C 的写入操作, 仅数据更新的顺序不同。 0066 如图 6 所示, 对于请求方 1 100 和请求方 2 100 分别对应引入记录方 1 200 和记 录方 2 200 。 0067 其中请求方1 100首先通过步骤401、 402和403向记录方1 200注册更新数据A、 C 和 B, 并在最后一次会话结束时提交请求 ( 步骤 404)。然后, 记录方 1 200 在向数据库更 新数据前, 先读取预先定义的数据更新顺序规则 (update order rule 。

29、data), 根据规则对 需要执行的更新请求进行排序 ( 步骤 405), 再依序向数据库发出更新请求, 开始事务 1( 步 骤 406)。接着执行步骤 407、 408 和 409, 向数据库更新事务, 最后提交事务 1( 步骤 410)。 0068 同样地, 请求方 2 100 首先通过步骤 501、 502 和 503 向记录方 2 200 注册更新 数据 B、 A 和 C, 并在最后一次会话结束时提交请求 ( 步骤 504)。然后, 记录方 2 200, 在向 数据库更新数据前, 读取预先定义的数据更新顺序规则, 根据规则对需要执行的更新请求 进行排序 ( 步骤 505), 再依序向数。

30、据库发出更新请求, 开始事务 2( 步骤 506)。接着执行步 骤 507、 508 和 509, 向数据库更新事务, 最后提交事务 2( 步骤 510)。 0069 如图 6 所示, 当事务 2 更新表 A 中的记录 A1 时, 首先需要获取排他锁, 当事务 1 尝 试更新同一笔记录时, 由于该数据已被事务 2 锁定, 需要等待事务 2 提交后, 表 A 上的排他 锁释放, 事务 1 才能开始对表 A 进行更新。因此, 当系统中所有数据更新都依照预先定义的 顺序规则进行, 就可以有效避免前述死锁情况。 0070 本发明通过将多次数据库写入操作合并, 从而减少数据库访问次数, 并缩小数据 库事。

31、务的跨度。因此, 显著提高应用系统数据库的更新效率。 0071 在执行并行更新事务时, 通过进一步建立数据更新顺序规则并根据规则对需要执 行的更新请求进行排序, 可便于管理数据库写入操作的执行顺序, 从而避免不必要的死锁。 0072 当然, 本发明还可有其它多种实施例, 在不背离本发明精神及其实质的情况下, 熟 悉本领域的技术人员当可根据本发明作出各种相应的改变和变形, 但这些相应的改变和变 说 明 书 CN 103136308 A 8 6/6 页 9 形都应属于本发明所附的权利要求的保护范围。 说 明 书 CN 103136308 A 9 1/5 页 10 图 1 说 明 书 附 图 CN 103136308 A 10 2/5 页 11 图 2 图 3 说 明 书 附 图 CN 103136308 A 11 3/5 页 12 图 4 说 明 书 附 图 CN 103136308 A 12 4/5 页 13 图 5 说 明 书 附 图 CN 103136308 A 13 5/5 页 14 图 6 说 明 书 附 图 CN 103136308 A 14 。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 物理 > 计算;推算;计数


copyright@ 2017-2020 zhuanlichaxun.net网站版权所有
经营许可证编号:粤ICP备2021068784号-1