数据库装置、对共享数据进行处理的方法及系统的制作方法

专利名称：数据库装置、对共享数据进行处理的方法及系统的制作方法
技术领域：
本发明涉及通信系统中的数据库技术，特别涉及一种数据库装置、对共 享数据进行处理的方法及系统。
背景技术：
IP多媒体子系统(IP Multimedia Subsystem,筒称IMS )可以实现包括语 音、视频、数据在内的新一代多媒体业务。在IMS中，应用服务器(Application Server,简称AS )用于提供增值的多媒体业务，归属用户服务器(简称HSS ) 用于保存用户数据，当用户需要使用某个AS提供的业务时，该AS会通过 Sh接口向HSS获取用户数据。随着新兴网络及业务的引入，业务及用户的数 量大增，为了更好地管理众多的业务及其对应的用户数据，出现了融合数 据库技术。在融合数据库技术中，多个网元中的用户数据集中存储在融合 数据库中，例如，在IMS中，可以对各HSS进行业务与数据的分离，执 行业务功能的为归属用户月艮务器前端(HSS Front End,简称HSS FE )， 各业务与数据分离后的HSS中的数据集中存储在融合数据库中。各AS可 以通过对应的HSS FE访问融合^t据库，也可以通过统一的^~口直《1妄访问 融合数据库。在IMS中，可能有多个AS为用户提供相同的业务，因此， 对于同一个业务数据可能会有多个AS对其进行修改。以两个AS访问融 合数据库为例，若这两个AS均通过同一个HSS FE访问数据库时，当该 HSS FE接收到其中 一个AS发送的Sh接口更新请求后，HSS FE需要检查 该Sh接口更新请求中由业务标识(Servicelndication )标识的业务数据当 前是否正在被另一个AS更新，如果正在被另一个AS更新，则会向该发 起Sh接口更新请求的AS返回响应，表明该数据正在被更新，该AS便会获知发生了并发事件。
但是，若这两个AS通过不同的HSS FE分别访问融合数据库，或者 这两个AS分别直接访问融合数据库的情况下，同样在上述并发事件发生 时，即两个AS发送的更新请求中携带的业务标识(Servicelndication)及 顺序号(SequenceNumber)是相同的融合数据库会更新相应的业务数据， 更改其顺序号，并向首先发起业务数据更新请求的AS返回更新成功的响 应；对于并发事件的另一个AS,对该另一个AS的更新请求进行排队，在 首先发起更新请求的AS发送的更新请求处理完毕后，再对该另一个AS 发送的更新请求进行处理。
发明人在实现本发明的过程中发现现有技术至少存在如下问题现有技 术中在发生并发时会对后一个更新请求自行进行排队处理，但是可能正在处 理的更新请求需要占用很长时间，若后一个更新请求一直在排队等待处理， 会造成发送后一个更新请求的应用方效率的下降。

发明内容
本发明是提供一种数据库装置，对共享数据进行处理的方法及系统，解 决现有技术中存在的并发事件发生时，不能明确通知请求更新的应用方发生 了并发事件的问题。
本发明实施例提供了 一种对共享数据进行处理的方法，包括
接收应用方发送的对数据项的更新请求；
判断是否存在其它应用方正在对所述数据项进行并发操:作；
若存在其它应用方正在对所述数据项进行并发操作，判断是否需要对所 述更新请求进行排队；
若不需要对所述更新请求进行排队，则向所述应用方返回所述更新请求 的响应消息。
本发明实施例提供了一种数据库装置，包括接收模块，用于接收应用方发送的对数据项的更新请求；
第一判断模块，用于判断是否存在其它应用方正在对所述接收模块接收 的更新请求中针对的数据项进行并发操作；
第二判断模块，用于在所述第一判断模块判断出存在其它应用方正在对 所述数据项进行并发操作时，判断是否需要对所述更新请求进行排队；
响应模块，用于在所述第二判断模块判断出不需要对所述更新请求进行 排队，向所述应用方返回所述更新请求的响应消息。
本发明实施例提供了一种对共享数据进行处理的系统，包括
第一应用方装置，用于发送对数据项的更新请求，所述更新请求中携 带表明若发生并发操作该更新请求是否需要排队的信息；
第一数据库装置，用于在判断出存在其它应用方对所述数据项进行并 发操作时，根据所述更新请求中携带的表明若发生并发操作该更新请求是 否需要排队的信息判断是否需要对所述更新请求进行排队，并在判断出不 需要对所述更新请求进行排队时，向所述第一应用方装置返回所述更新请求 的响应消息。
本发明实施例还提供了一种对共享数据进行处理的系统，包括
第二应用方装置，用于发送对数据项的更新请求；
第二数据库装置，用于在判断出存在其它应用方对所述数据项进行并 发操作时，根据预先配置的信息判断是否需要对所述更新请求进行排队， 并在判断出不需要对所述更新请求进行排队时，向所述第二应用方装置返回 所述更新请求的响应消息，所述预先配置的信息表示当特定数据类型或数据 项发生并发操作是否需要排队。
本发明实施例还提供了一种对共享数据进行处理的系统，包括
第三应用方装置，用于发送对数据项的更新请求，所述更新请求中携 带表明若发生并发操作该更新请求是否需要排队的信息；
第三数据库装置，预先配置有表示特定数据类型或数据项发生并发操作是否需要排队的预设信息，以及接收到的更新请求中携带的表明若发生并 发操作该更新请求是否需要排队的信息和所述预设信息的优先级级别，用 于在判断出存在其它应用方对所述数据项进行并发#:作时，根据所述优先 级级别判断是否需要对所述更新请求进行排队，并在判断出不需要对所述 更新请求进行排队时，向所述第三应用方装置返回所述更新请求的响应消息。 由上述技术方案可知，本发明实施例在发生并发事件时，通过判断是否 需要排队，向不需要排队的更新请求对应的应用方返回响应，节省该应用方 等待的时间，有利于提高应用方的处理效率，同时也可以提高数据库的处理 效率及节省数据库内部资源。


图1为本发明对共享数据进行处理的方法实施例一的流程示意图； 图2为本发明对共享数据进行处理的方法实施例二的流程示意图； 图3为本发明对共享数据进行处理的方法实施例三的流程示意图； 图4为本发明对共享数据进行处理的方法实施例四的流程示意图； 图5为本发明数据库装置实施例的结构示意图； 图6为本发明对共享数据进行处理的系统实施例一的结构示意图； 图7为本发明对共享数据进行处理的系统实施例二的结构示意图； 图8为本发明对共享教:据进行处理的系统实施例三的结构示意图。
具体实施例方式
图1为本发明对共享数据进行处理的方法实施例一的流程示意图，包括 步骤11:承载有融合数据库的设备(以下简称数据库装置)接收应用方
发送的对数据项的更新请求，该更新请求具体可以是对数据的增加、删除、
修改或查询的任意 一种操作请求。
步骤12:数据库装置判断是否存在其它应用方正在对所述数据项进行更新操作，即判断是否发生了并发操作，其中，该应用方与其它应用方的操作请求可以相同也可以不同，若是，执行步骤13，若否，可以进一步地执行步
骤16。
步骤13:数据库装置判断是否需要对所述更新请求进行排队，若否，执行步骤14,进一步地，若是，执行步骤15。
步骤14:数据库装置向所述一应用方返回该更新请求的响应。例如，为了使应用方明确地获知发生了并发操作，可以向该应用方返回表明发生了并发操作的响应消息。
步骤15:数据库装置对该更新请求进行排队处理。如将其它应用方对该数据项的更新请求处理完毕后，处理该更新请求。
步骤16:数据库装置处理该更新请求。如修改该更新请求中指定的数据项。本实施例在存在并发事件情况下，通过判断是否需要对一更新请求进行排队，若不排队，数据库装置可以及时向发出该更新请求的应用方返回响应，而不需要对该更新请求进行操作，因此可以提高数据库装置的处理效率；进一步的，可以在返回的相应消息中携带表明发生了并发操作的指示，使得应用方可以及时获知发生了并发操作，而不再无限的等待，并采取相关的措施，因此可以提高应用方的处理效率。
实施例一中，数据库装置可以根据更新请求中携带的信息或者预先配置的信息判断是否需要对更新请求进行排队，另外，该更新请求中还可以进一步地携带，或者预先配置的信息还可以进一步地设置缺省或指定的时间信息，缺省或指定时间用来表明若并发的操作在该缺省或指定时间后没有结束，贝不再排队，返回更新请求的响应消息。则步骤15数据库装置对该更新请求进行排队时，根据该缺省或指定时间进一步执行判断是否需要对所述更新请求进行排队的步骤，若该缺省或指定时间没有结束，则继续排队，若该缺省或指定时间结束且所述并发操作仍没有结束，则不再排队，返回更新请求的响应消息。
10相应的具体实施例可参见下述的各实施例。
图2为本发明对共享数据进行处理的方法实施例二的流程示意图，该实施例以AS通过HSS FE访问融合数据库、且HSS FE采用轻型目录访问协议(Lightweight Directory Access Protocol,简称LDAP ) 问融合凄丈据库为例。该实施例包括
步骤21:第一 HSS FE在接收到第一 AS发送的Sh接口更新请求(Sh-Update)后，向数据库装置发送更新请求(例如LDAP Modify )。更新请求中携带要修改的数据项，该数据项的版本信息(例如业务标识及顺序号)，同时携带表明本次更新请求若发生并发操作是否排队的信息，该信息可以表明若存在其他应用方对该数据项进行修改时，则需要数据库直接返回并发响应，而不要在数据库中排队，也可以表明若存在并发操作，数据库需要将本更新请求在数据库中进行排队。该信息可以通过扩展的LDAP参数来实现，在更新请求中携带扩展的参数的具体实现方式如下
方式一通过扩展LDAP协议中的控制参数(Control)来携带该参数。Control是用于在不修改LDAP协议本身的前提下扩展LDAP的功能。例如可以增加一个新的LDAP Control (如UrgentControl),通过此UrgentControl说明此操作不允许并发，若此条目正在被操作，则返回响应信息，不进行排队处理。该Urgent Control格式如下。
Control ::= SEQUENCE {
controlTypeLDAPOID，—例如，将LDAPOID的值设为1.3.6.1.1.13
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL—可以用于指定时间
}
上述对UrgentControl的定义只是作为示例，也可以采用其他的定义方式。方式二通过扩展LDAP协议的消息体来携带该参数。例如，增加新的参数(如Urgent)，该参数具体可以在LDAP涉及的所有更新操作中增加，LDAP涉及的更新操作包括增加(Add)、删除(Delete)、修改(Modify)操作。以修改(Modify)操作为例，包括该扩展参数的Modify格式如下
ModifyRequest [APPLICATION 6] SEQUENCE {
object LDAPDN，
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),delete (1),replace (2)，
…}，
modification PartialAttribute，urgentlndication BOOLEAN,urgentTime INTEGER } }
其中，上述的urgentindication以及urgenttime参数是新增的，用来说明该修改操作是否需要进行排队以及指定时间。
该更新请求中还可以进一步地携带缺省或指定时间，缺省/指定时间用来表明在该时间段内并发的操作如果没有结束，则不再排队，返回更新请求的响应消息。
步骤22:若此时没有对该数据项的更新操作，即数据库装置判断出该数据项没有并发操作，则开始对该数据项进行正常的更新操:作。
步骤23:第二 HSS FE在接收到第二 AS发送的Sh接口更新请求(Sh-Update)后，向数据库装置发送更新请求。如第一 HSS FE发送的更新请求一样，该更新请求中携带包含要修改的数据项，该数据项的版本信息，以及本次请求若发生并发操作是否需要排队的信息，本实施例中该信息表明如果有对该数据项的并发操作，则融合数据库直接返回并发处理响应，而不要对该修改命令进行排队。
步骤24:数据库装置接收到第二HSS FE发送的更新请求后，若此时数
12据库装置正在对第一HSS FE发送的更新请求进行处理，即数据库判断出数 据项正在被处理。
步骤25:数据库装置向第二HSS FE返回更新响应，该响应表明发生了 并发操作。需要说明的是，融合数据库也可以直接返回响应消息而不指明发 生并发操作。
步骤21中实现了对请求的扩展，步骤25需要对响应进行扩展，对响 应消息的扩展可以通过下述的两种方式实现
方式一通过扩展响应消息中的结果代码(ResultCode)值，即增加新的 ResultCodeY直(^口ResultCode-Concurrent)。
方式二 通过在响应消息中携带新的控制参数Control (如Concurrence Control),新增加的Control的具体格式如下
Control ::= SEQUENCER
controlType LDAPOID,—例如，将LDAPOID的值设为
1.3.6.1.1.13
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL—可以用于表示发生
并发
在方式二中，响应消息的ResultCode可以是某种形式的错误指示，如 operationsError。
本实施例可以使AS明确获知发生了并发操作，若某个比较耗时的更新 请求发生并发时，可以使该AS不必等待，因此可以节省该AS等待的时间， 有利于提高应用方的处理效率，数据库及时向应用返回发生并发的响应时， 可以提高数据库的处理效率及节省数据库内部资源。进一步的，融合数据库 可以在返回的相应消息中携带表明发生了并发操作的指示，使得应用方可以 及时获知发生了并发操作，而不再无限的等待，并采取相关的措施，因此可以提高应用方的处理效率。
步骤26:数据库装置对第一 HSS FE的更新请求处理完毕，向第一 HSS FE 返回成功响应(长口 ResultCode=Success )。
本实施例以更新请求中携带是否需要排队的信息为例，示出了并发处理 的流程。同时，本实施例以LDAP协议为例，示出了为了携带上述信息进行 的扩展的具体实现方式。通过本实施例的流程，可以提高系统效率，节省系 统资源。
图3为本发明对共享数据进行处理的方法实施例三的流程示意图，该实 施例以AS直接访问融合数据库、且采用可扩展标识语言配置访问协议 (extensible Markup Language Configuration Access Protocol,简称XCAP)访 问融合数据库为例。该实施例包括
步骤31:第一AS向数据库装置发送更新请求(XCAP Replace)。更新 请求中如现有技术一样要携带要修改的数据项，该数据项的版本信息(例如 业务标识及顺序号)，还要携带本次请求若发生并发，喿作是否排队的信息， 本实施例中该信息表明若存在其他应用方对该数据项进行修改时，则需要数 据库直接返回并发响应，而不要在数据库中排队。
其中，该信息通过扩展的协议实现，具体可以在XCAP涉及的所有更 新操作中以增加相关标签或者标识参数的方式实现，XCAP涉及的更新操 作包括创建/替换(PUT)、删除(DELETE)操作。例如，可以在PUT 或者DELETE中增加一个标签或者标识参数(如Urgent),该标签或者标 识参数的值(如Urgentlndication)用来说明是否进行排队，并且还可以进 一步的表明缺省或指定时间，缺省或指定时间用来表明在该时间段内并发 的操作如果没有结束，则不再排队，返回更新请求的响应消息。
步骤32:若此时没有对该数据项的更新操作，即数据库装置判断出该数 据项没有并发操作，则开始对该数据项进行正常的更新l喿作。
步骤33:第二 AS向数据库装置发送更新请求。如第一 AS发送的更新请求一样，该更新请求中携带包含要修改的数据项，该数据项的版本信息， 以及本次请求若发生并发操作是否排队的信息，该信息表明如果有对该数据 项的并发操作，则融合数据库直接返回并发处理响应，而不要对该修改命令 进行排队。需要说明的是，融合数据库也可以直接返回响应消息而不指明发 生并发操作。
步骤34:数据库装置接收到第二 AS发送的更新请求后，若此时数据库 装置正在对第一 AS发送的更新请求进行处理，即数据库判断出数据项正在 被处理。
步骤35:数据库装置向第二AS返回响应，该响应表明发生了并发操作。 例如，使用XCAP的HTTP 409响应，在响应的消息体中包含错误指示，表 明发生了并发操作。
与现有技术中这种情况下出现的返回同步错误的信息相比，本实施例可 以使AS明确获知发生了并发操作，并进一步可以进行基于并发的后续操:作。
步骤36:数据库装置对第一AS的更新请求处理完毕，向第一AS返回 成功响应。
本实施例以更新请求中携带是否需要排队的信息为例，示出了并发处理 的流程。同时，本实施例以XCAP协议为例，示出了为了携带上述信息进行 的扩展的具体实现方式。通过本实施例的流程，可以提高系统效率，节省系 统资源。
图4为本发明对共享数据进行处理的方法实施例四的流程示意图，该实 施例以数据库装置根据预先配置的信息判断是否对更新请求进行排队处理为
其他的网元。该实施例包括
步骤41:第一应用方向数据库装置发送更新请求。 步骤42:数据库装置对该更新请求进行处理。
步骤43:第二应用方向数据库装置发送更新请求。该更新请求要求更新
15的数据项与第 一应用方要求更新的数据项相同。
步骤44:数据库装置纟艮据预先配置的信息决定对该更新请求不进行排队 处理。
其中，预先配置的信息的具体实现方式如下
方式一以LDAP为例，可以在LDAP的数据模型(Schema)中描述当 特定数据类型或数据项产生并发操作时，是否对相应的更新请求进行排队的 信息。
LDAP中的信息模式，类似于面向对象的概念，在LDAP中每个条目 属于某个或者多个对象类(ObjectClass ),每个ObjectClass由多个属性类 型组成，每个属性类型有所对应的语法和匹配规则；对象类和属性类型的 定义均可以使用继承的概念。每个条目创建时，必须定义所属的对象类， 必须提供对象类中的必选属性类型的属性值(Attribute)，在LDAP中一 个属性类型可以对应多个值。在LDAP中把对象类、属性类型、语法和匹 配MJ'j统称为Schema。因此，在配置时，可以对Schema中的属性Attribute、 对象类ObjectClass、目录信息树内容规则DITContentRule、目录信息树结构 规则DITStructureRule、名称形式NameForm进行扩展，以说明针对特定的数 据类型、It据项发生并发事件时，是否对相应的更新请求进行排队处理。以 对Attribute的扩展为例，具体的扩展方式如下(格式参见RFC4512):
扩展(Extensions)为X-Urgent "0"
其中，"Urgent"为扩展名称，表明发生并发时，针对某一数据项或数 据类型的更新请求是否进行排队；"0"为时间阈值(缺省或指定时间)，表 示在该数值表示的时间段内并发的操作如果没有结束，则返回发生并发的消 息响应，该值可以根据配置需求设置为其他的数字。
方式二可以通过配置文件、图表等方式预先存储配置信息。例如，可 以在配置文件或图表中记录数据名称或数据类型或应用类型或操作类型等参 数及对这些参数是否排队。
16步骤45:数据库装置向第二应用方返回响应，表明发生了并发。具体可 以为通过扩展现有响应消息中的结果代码(ResultCode)值，即增加新 的ResultCode值(^口 ResultCode=Concurrent)
步骤46:数据库装置对第一应用方的更新请求处理完毕，向第一应用方 返回成功响应(^口 ResultCode-Success )。
本实施例是根据内部存储的预先配置的信息进行判断，并给出了相应的 处理流程。通过本实施例的流程，可以使AS明确获知发生了并发操作，若 某个比较耗时的更新请求发生并发时，可以使该AS不必等待，因此可以节 省该AS等待的时间，有利于提高应用方的处理效率，数据库及时向应用返 回发生并发的响应时，可以提高数据库的处理效率及节省凝:据库内部资源。 进一步的，融合数据库可以在返回的相应消息中携带表明发生了并发操作的 指示，使得应用方可以及时获知发生了并发操作，而不再无限的等待，并采 取相关的措施，因此可以提高应用方的处理效率。
本实施例中还可以如实施例二、三一样在更新请求中携带信息，即更新 请求中携带表明是否对该更新请求进行排队的信息，且数据库装置中还预先 配置有预设信息，此时可以设置所述表明该更新请求若发生并发操作是否需 要排队的信息与所述预先配置的信息的优先级级别，根据优先级级别确定是 根据更新请求中的信息还是预设信息判断是否对更新请求进行排队，例如， 设置更新请求中携带的信息的优先级高于预设信息，则数据库将根据更新请 求中携带的信息进行是否排队的判断。其中优先级级别的设置可以通过在数 据库的配置文件中设置一个关键字(Priority)及对应的内容，根据该关键字中 内容(如请求的优先级级别高)确定出优先级级别。
本实施例的预设信息可以是表明针对数据项的更新请求是否排队的信 息，此时可以根据该信息直接进行是否排队的判断，或者本实施例中的预设 信息还可以包含时间阈值，若在该时间阈值内并发操作没有结束，则不再对 更新请求排队，直接返回响应，例如上述步骤44中的方式一。特别的，实施例二、三中，应用方可以根据自身的需要来决定对于一更 新操作如果有并发产生时，是否需要进行排队。这样，如果某个比较耗时的 更新操作发生并发时，应用方可以及时获知并发的信息，进而可以不再等待，
实现节省时间、提高应用方的处理效率；实施例四中，数据库装置可以根据 自身的需要来决定针对某一数据项的并发发生时，是否对后到的更新请求进 行排队处理。这样，如果针对某个数据项的更新操作比较复杂耗时，可以不 对其进行排队而是返回并发的响应，实现提高数据库装置的处理效率及节省 数据库装置的内部资源。
本领域普通技术人员可以理解实现上述方法实施例的全部或部分步 骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机 可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤； 而前述的存储介质包括ROM、 RAM、》兹碟或者光盘等各种可以存储程 序代码的介质。
图5为本发明数据库装置实施例的结构示意图，包括接收模块51、第 一判断模块52、第二判断模块53和响应模块54。接收模块51用于接收应用 方发送的对数据项的更新请求，并将该更新请求发送给第一判断模块52;第 一判断模块52用于从接收模块51获取该更新请求后，判断是否存在其它应 用方正在对该更新请求中针对的数据项进行更新操作，若是，则将该更新请 求发送给第二判断模块53;第二判断模块52用于在第一判断模块52判断出 存在其它应用方对所述数据项进行更新操作时，判断是否需要对该更新请求 进行排队，若是，触发响应模块54的运行；响应模块54用于在第二判断模 块53判断出不需要对该更新请求进行排队，向所述应用方返回该更新请求的 响应消息，如表明发生并发操作的响应。
具体的，接收模块51用于接收携带表明若发生并发操作该更新请求是否 需要排队的信息的更新请求；第二判断模块53用于根据所述表明若发生并发 操作该更新请求是否需要排队的信息判断是否需要对所述更新请求进行排队。
或者，该数据库装置还可以进一步的包括预设^^块，该预设模块用于存
储预先配置的预设信息；此时，接收模块51可以用于接收更新请求，第二判 断模块53用于根据所述预设模块中存储的预设信息判断是否需要对所述更 新请求进行排队。
其中预设模块中存储的预设信息可以是用于表明针对所述数据项的更新 请求是否需要排队的信息；第二判断模块53用于根据该预设信息判断是否需 要对所述更新请求进行排队。或者，所述预设信息进一步包括时间阈值，所 述第二判断模块53具体用于在其它应用方达到所述时间阈值后依旧对所述 数据项进行更新才喿作时，判断出不再对所述更新请求进行排队。
若该装置接收的所述更新请求中携带表明该更新请求是否需要排队的信 息，且该装置中存储有预先配置的预设信息，则该装置还包括优先级设置模 块，该优先级设置模块用于设置更新请求中携带的信息与预设信息的优先级； 所述第二判断^t块具体用于根据所述优先级确定判断依据，根据所述判断依 据判断是否需要对所述更新请求进行排队。
本实施例还可以进一步包括排队模块，排队模块用于在第二判断模块判 断出需要对该更新请求进行排队时，对该更新请求进行排队处理。
本实施例在存在并发事件情况下，通过判断是否需要对一更新请求进行 排队，若不排队，该数据库装置可以及时向发出该更新请求的应用方返回表 明发生了并发操作的响应，而不需要对该更新请求进行操作，因此可以提高 数据库装置的处理效率；同时，应用方可以及时获知发生了并发操作，而不 再无限的等待，因此可以提高应用方的处理效率。
图6为本发明对共享数据进行处理的系统实施例一的结构示意图，包 括第一应用方装置61和第一数据库装置62。第一应用方装置61用于发送 对数据项的更新请求，所述更新请求中携带表明若发生并发操作该更新请 求是否需要排队的信息；第一数据库装置62用于接收第一应用方装置61判断出存在其它应用方对所述数据项进行更新操 作时，根据所述更新请求中携带的表明若发生并发操作该更新请求是否排 队的信息判断是否需要对所述更新请求进行排队，并在判断出不需要对所
述更新请求进行排队时，向所述第一应用方装置61返回该更新请求的响应消
息，如表明发生并发操作的响应。
本实施例在存在并发事件情况下，数据库装置根据应用方装置发送的更 新请求中携带的信息进行排队与否的判断，若不排队，数据库装置可以及时 向发出该更新请求的应用方装置返回表明发生了并发操作的响应，而不需要
对该更新请求进行操作，因此可以提高数据库装置的处理效率；同时，应用 方装置可以及时获知发生了并发搡作，而不再无限的等待，因此可以提高应 用方装置的处理效率。
图7为本发明对共享数据进行处理的系统实施例二的结构示意图，包 括第二应用方装置71和第二数据库装置72。第二应用方装置71用于发送 对数据项的更新请求；第二数据库装置72用于接收第二应用方装置71发 送的该更新请求，并在判断出存在另 一应用方对所述数据项进行更新操作 时，根据预先配置的预设信息判断是否需要对所述更新请求进行排队，并 在判断出不需要对所述更新请求进行排队时，向第二应用方装置71返回该更 新请求的响应消息，如表明发生并发操作的响应，该预设信息表示当特定数 据类型或数据项发生并发操作是否需要排队。
本实施例在存在并发事件情况下，数据库装置根据预先配置的信息进行 排队与否的判断，若不排队，数据库装置可以及时向发出该更新请求的应用 方装置返回表明发生了并发操作的响应，而不需要对该更新请求进行操作， 因此可以提高数据库装置的处理效率；同时，应用方装置可以及时获知发生 了并发操作，而不再无限的等待，因此可以提高应用方装置的处理效率。
图8为本发明对共享数据进行处理的系统实施例三的结构示意图，包 括第三应用方装置81和第三数据库装置82。该系统结合了实施例一和实
20施例二的信息，即第三应用方装置81用于发送对数据项的更新请求，所 述更新请求中携带表明若发生并发操作该更新请求是否需要排队的信息； 第三数据库装置82预先配置有预设信息，该预设信息表示当特定数据类型 或数据项发生并发操作是否需要排队。即更新请求中存在判断依据，同时预 先配置有判断依据，因此需要确定判断依据；为此，第三数据库装置82 还需要进一步配置有更新请求中信息和所述预设信息的优先级级别。第三 数据库装置82用于在判断出存在其它应用方对所述数据项进行更新操作 时，根据该优先级级别确定是否排队，具体可以为首先根据所述优先级信 息确定判断依据，再根据所述判断依据判断是否需要对所述更新请求进行 排队(例如，更新请求中信息的优先级高于预设信息的优先级，则根据更 新请求中的信息判断是否对更新请求进行排队，反之亦然)，并在判断出 不需要对所述更新请求进行排队时，向所述第二应用方装置返回该更新请求 的响应消息，如表明发生并发操作的响应。
本实施例在存在并发事件情况下，数据库装置首先根据优先级确定判断 依据，再根据确定的判断依据进行排队与否的判断，若不排队，数据库装置 可以及时向发出该更新请求的应用方装置返回表明发生了并发操作的响应， 而不需要对该更新请求进行操作，因此可以提高数据库装置的处理效率；同 时，应用方装置可以及时获知发生了并发操作，而不再无限的等待，因此可 以提高应用方装置的处理效率。
最后应说明的是以上实施例仅用以说明本发明的技术方案而非对其进 行限制，尽管参照较佳实施例对本发明进行了详细的说明，本领域的普通技 术人员应当理解其依然可以对本发明的技术方案进行修改或者等同替换， 而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的 4青神和范围。
权利要求
1、一种对共享数据进行处理的方法，其特征在于，包括接收应用方发送的对数据项的更新请求；判断是否存在其它应用方正在对所述数据项进行并发操作；若存在其它应用方正在对所述数据项进行并发操作，判断是否需要对所述更新请求进行排队；若不需要对所述更新请求进行排队，则向所述应用方返回所述更新请求的响应消息。
2、 根据权利要求1所述的方法，其特征在于，所述更新请求中携带表明 若发生并发操作该更新请求是否需要排队的信息；所述判断是否需要对所述 更新请求进行排队具体包括根据所述表明若发生并发操作该更新请求是否 需要排队的信息判断是否需要对所述更新请求进行排队。
3、 根据权利要求2所述的方法，其特征在于通过扩展轻型目录访问协 议的控制参数，或者扩展轻型目录访问协议的消息体来携带所述表明若发生 并发操作该更新请求是否需要排队的信息。
4、 根据权利要求2所述的方法，其特征在于通过在可扩展标识语言配 置访问协议中增加标签或标识参数的方式来携带所述表明若发生并发操作该 更新请求是否需要排队的信息。
5、 根据权利要求l所述的方法，其特征在于，所述判断是否需要对所述 更新请求进行排队具体包括根据预先配置的信息判断是否需要对所述更新 请求进行排队，所述预先配置的信息表示特定数据类型或数据项发生并发操 作是否需要排队。
6、 根据权利要求5所述的方法，其特征在于通过扩展轻型目录访问协 议的数据模型用以描述所述预先配置的信息；或者，通过配置文件或图表的 方式存储所述预先配置的信息。
7、 根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括若需要对所述更新请求进行排队，则对所述更新请求进行排队处理。
8、 根据权利要求7所述的方法，其特征在于，所述更新请求中进一步携带缺省或指定的时间信息，或者，所述预先配置的信息进一步包含缺省或指定的时间信息，所述缺省或指定时间信息表明若并发的操作在该缺省或指定时间后没有结束，则不再排队，返回更新请求的响应消息；相应的，对所述更新请求进行排队处理时，进一步根据所述缺省或指定时间判断是否需要对所述更新请求进行排队，若该缺省或指定时间结束且所述并发操作仍没有结束，则不再排队，返回所述更新请求的响应消息。
9、 根据权利要求1所述的方法，其特征在于，所述更新请求中携带表明若发生并发操作该更新请求是否需要排队的信息，数据库预先配置有表示特定数据类型或数据项发生并发操作是否需要排队的信息；所述方法进一步包括设置所述表明若发生并发操作该更新请求是否需要排队的信息与所述预先配置的信息的优先级级别；所述判断是否需要对所述更新请求进行排队具体包括根据所述优先级级别判断是否需要对所述更新请求进行排队。
10、 根据权利要求1至6任一项、8或9所述的方法，其特征在于，所述返回所述更新请求的响应消息包括向应用方返回表明发生并发操:作的响应消息。
11、 根据权利要求IO所述的方法，其特征在于，所述向应用方返回表明发生并发操作的响应消息包括通过扩展响应消息中的结果代码或者在响应消息中携带新的控制参数表明发生并发操作。
12、 一种数据库装置，其特征在于，包括接收模块，用于接收应用方发送的对数据项的更新请求；第一判断模块，用于判断是否存在其它应用方正在对所述接收模块接收的更新请求中针对的数据项进行并发操作；第二判断模块，用于在所述第 一判断模块判断出存在其它应用方正在对所述数据项进行并发操作时，判断是否需要对所述更新请求进行排队；响应模块，用于在所述第二判断模块判断出不需要对所述更新请求进行 排队，向所述应用方返回所述更新请求的响应消息。
13、 根据权利要求12所述的装置，其特征在于所述接收模块接收的更新请求中携带表明若发生并发操作该更新请求是 否需要排队的信息；所述第二判断模块用于根据所述表明若发生并发操作该更新请求是否需 要排队的信息判断是否需要对所述更新请求进行排队。
14、 根据权利要求12所述的装置，其特征在于，还包括预设模块，用于存储预先配置的信息，所述预先配置的信息表示特定数 据类型或数据项发生并发操作是否需要排队；所述第二判断模块用于根据所述预设模块中存储的预先配置的信息判断 是否需要对所述更新请求进行排队。
15、 根据权利要求14所述的装置，其特征在于若所述更新请求中携带表明若发生并发操作该更新请求是否需要排队的 信息，则该装置还包括优先级设置模块，用于设置更新请求中携带的表明若 发生并发操作该更新请求是否需要排队的信息与预先配置的信息的优先级级 别；所述第二判断才莫块具体用于根据所述优先级级别判断是否需要对所述更新请求进行排队。
16、 根据权利要求12所述的装置，其特征在于，还包括排队模块，用 于在所述第二判断模块判断出需要对所述更新请求进行排队时，对所述更新 请求进行排队处理。
17、 一种对共享数据进行处理的系统，其特征在于，包括 第一应用方装置，用于发送对数据项的更新请求，所述更新请求中携带表明若发生并发操作该更新请求是否需要排队的信息；第 一数据库装置，用于在判断出存在其它应用方对所述数据项进行并发操作时，根据所述更新请求中携带的表明若发生并发操作该更新请求是 否需要排队的信息判断是否需要对所述更新请求进行排队，并在判断出不 需要对所述更新请求进行排队时，向所述第一应用方装置返回所述更新请求 的响应消息。
18、 一种对共享数据进行处理的系统，其特征在于，包括 第二应用方装置，用于发送对数据项的更新请求； 第二数据库装置，用于在判断出存在其它应用方对所述数据项进行并发操作时，根据预先配置的信息判断是否需要对所述更新请求进行排队， 并在判断出不需要对所述更新请求进行排队时，向所述第二应用方装置返回 所述更新请求的响应消息，所述预先配置的信息表示特定数据类型或数据项 发生并发操作是否需要排队。
19、 一种对共享数据进行处理的系统，其特征在于，包括 第三应用方装置，用于发送对数据项的更新请求，所述更新请求中携带表明若发生并发操作该更新请求是否需要排队的信息；第三数据库装置，预先配置有表示特定数据类型或数据项发生并发操作 是否需要排队的预设信息，以及接收到的更新请求中携带的表明若发生并 发操作该更新请求是否需要排队的信息和所述预设信息的优先级级别，用 于在判断出存在其它应用方对所述数据项进行并发操作时，根据所述优先 级级别判断是否需要对所述更新请求进行排队，并在判断出不需要对所述 更新请求进行排队时，向所述第三应用方装置返回所述更新请求的响应消息。
全文摘要
本发明公开了一种数据库装置、对共享数据进行处理的方法及系统。该方法包括接收应用方发送的对数据项的更新请求；判断是否存在其它应用方正在对所述数据项进行并发操作；若存在其它应用方对所述数据项进行并发操作，判断是否需要对所述更新请求进行排队；若不需要对所述更新请求进行排队，则向所述应用方返回所述更新请求的响应消息。通过本发明实施例可以使应用方及时获知发生了并发操作，进而提高工作效率、节省资源。
文档编号G06F17/30GK101685460SQ20081022293
公开日2010年3月31日 申请日期2008年9月23日 优先权日2008年9月23日
发明者曹俊亮, 澜 王, 锋 苏, 鹏 荀 申请人:华为技术有限公司