CN101685460A - Database device, method and system for processing shared data - Google Patents

Abstract

The invention discloses a database device, a method and a system for processing shared data. The method includes receiving an update request for a data item sent by an application; judging whether there are other applications performing concurrent operations on the data item; if there are other applications performing concurrent operations on the data item, judging whether it is necessary to queue the update request; if the update request does not need to be queued, return a response message of the update request to the application side. Through the embodiments of the present invention, the application side can be informed of concurrent operations in time, thereby improving work efficiency and saving resources.

Description

Database device, method and system for processing shared data

technical field

The invention relates to the database technology in the communication system, in particular to a database device, a method and a system for processing shared data.

Background technique

The IP Multimedia Subsystem (IMS for short) can realize a new generation of multimedia services including voice, video and data. In IMS, the Application Server (AS for short) is used to provide value-added multimedia services, and the Home Subscriber Server (HSS for short) is used to store user data. When a user needs to use the service provided by an AS, the AS will pass the Sh The interface obtains user data from the HSS. With the introduction of emerging networks and services, the number of services and users has increased significantly. In order to better manage numerous services and their corresponding user data, a converged database technology has emerged. In the converged database technology, the user data in multiple network elements are stored in the converged database. For example, in the IMS, the service and data of each HSS can be separated, and the service function is performed by the home user server front end (HSS Front End, referred to as HSS FE), the data in the HSS after the separation of each business and data is centrally stored in the fusion database. Each AS can access the fusion database through the corresponding HSS FE, or directly access the fusion database through a unified interface. In the IMS, there may be multiple ASs that provide the same service for the user, therefore, there may be multiple ASs that modify the same service data. Taking two ASs accessing the fusion database as an example, if the two ASs access the database through the same HSS FE, when the HSS FE receives the Sh interface update request sent by one of the ASs, the HSS FE needs to check the Sh interface update Whether the service data identified by the service identification (ServiceIndication) in the request is currently being updated by another AS, if it is being updated by another AS, a response will be returned to the AS that initiated the Sh interface update request, indicating that the data is being updated, The AS will then be notified that a concurrent event has occurred.

However, if the two ASs access the fusion database through different HSS FEs, or the two ASs directly access the fusion database respectively, when the above concurrent events occur, that is, the update requests sent by the two ASs carry The service identification (ServiceIndication) and the sequence number (SequenceNumber) are the same: the fusion database will update the corresponding service data, change its sequence number, and return a successful update response to the AS that first initiated the service data update request; One AS queues the update request of the other AS, and processes the update request sent by the other AS after the update request sent by the AS that first initiates the update request is processed.

In the process of implementing the present invention, the inventor found at least the following problems in the prior art: in the prior art, when concurrency occurs, the next update request will be queued and processed by itself, but the update request that may be being processed may take a long time, If the latter update request has been queued for processing, the efficiency of the application sending the latter update request will decrease.

Contents of the invention

The present invention provides a database device, a method and system for processing shared data, and solves the problem in the prior art that when a concurrent event occurs, the application party requesting an update cannot be clearly notified that the concurrent event has occurred.

An embodiment of the present invention provides a method for processing shared data, including:

Receive an update request for data items sent by the application side;

Determine whether other applications are performing concurrent operations on the data item;

If other applications are performing concurrent operations on the data item, determine whether the update request needs to be queued;

If the update request does not need to be queued, return a response message of the update request to the application side.

An embodiment of the present invention provides a database device, including:

A receiving module, configured to receive an update request for a data item sent by the application side;

The first judging module is used to judge whether other application parties are performing concurrent operations on the data item targeted in the update request received by the receiving module;

The second judging module is configured to judge whether the update request needs to be queued when the first judging module judges that other applications are performing concurrent operations on the data item;

A response module, configured to return a response message of the update request to the application side when the second judging module judges that the update request does not need to be queued.

An embodiment of the present invention provides a system for processing shared data, including:

The first application device is configured to send an update request for a data item, and the update request carries information indicating whether the update request needs to be queued if concurrent operations occur;

The first database device is configured to determine whether other applications need to perform concurrent operations on the data items according to the information carried in the update request indicating whether the update request needs to be queued if concurrent operations occur. queue the update request, and return a response message of the update request to the first application device when it is determined that the update request does not need to be queued.

The embodiment of the present invention also provides a system for processing shared data, including:

The second application-side device is configured to send an update request for the data item;

The second database device is configured to determine whether the update request needs to be queued according to pre-configured information when it is determined that there are other applications performing concurrent operations on the data item, and when it is determined that the update request does not need to be performed When queuing is requested, a response message of the update request is returned to the second application device, and the pre-configured information indicates whether queuing is required when concurrent operations of a specific data type or data item occur.

The embodiment of the present invention also provides a system for processing shared data, including:

The third application-side device is configured to send an update request for the data item, and the update request carries information indicating whether the update request needs to be queued if concurrent operations occur;

The third database device is pre-configured with preset information indicating whether a concurrent operation of a specific data type or data item needs to be queued, and the information carried in the received update request indicating whether the update request needs to be queued if a concurrent operation occurs. The priority level of the preset information is used to judge whether the update request needs to be queued according to the priority level when it is judged that there are other applications performing concurrent operations on the data item, and when it is judged that there is no When the update request needs to be queued, return a response message of the update request to the third application device.

It can be seen from the above technical solution that in the embodiment of the present invention, when a concurrent event occurs, by judging whether queuing is required, a response is returned to the application party corresponding to the update request that does not need queuing, which saves the waiting time of the application party and is beneficial to improve the application party. It can also improve the processing efficiency of the database and save the internal resources of the database.

Description of drawings

FIG. 1 is a schematic flowchart of Embodiment 1 of the method for processing shared data in the present invention;

FIG. 2 is a schematic flow diagram of Embodiment 2 of the method for processing shared data in the present invention;

FIG. 3 is a schematic flowchart of Embodiment 3 of the method for processing shared data in the present invention;

FIG. 4 is a schematic flowchart of Embodiment 4 of the method for processing shared data in the present invention;

5 is a schematic structural diagram of an embodiment of a database device of the present invention;

FIG. 6 is a schematic structural diagram of Embodiment 1 of the system for processing shared data in the present invention;

7 is a schematic structural diagram of Embodiment 2 of the system for processing shared data in the present invention;

FIG. 8 is a schematic structural diagram of Embodiment 3 of the system for processing shared data according to the present invention.

Detailed ways

Fig. 1 is a schematic flowchart of Embodiment 1 of the method for processing shared data in the present invention, including:

Step 11: The device carrying the integrated database (hereinafter referred to as the database device) receives the update request for data items sent by the application side. The update request can be any operation request for adding, deleting, modifying or querying data.

Step 12: The database device judges whether other application parties are performing update operations on the data item, that is, determines whether concurrent operations have occurred, wherein the operation requests of this application party and other application parties can be the same or different, and if so, execute Step 13, if not, step 16 may be further performed.

Step 13: The database device judges whether the update request needs to be queued, if not, execute step 14, and further, if yes, execute step 15.

Step 14: The database device returns a response to the update request to the application side. For example, in order to let the application side clearly know that the concurrent operation has occurred, a response message indicating that the concurrent operation has occurred may be returned to the application side.

Step 15: The database device queues up the update request. For example, after processing the update requests of other applications for the data item, the update request is processed.

Step 16: The database device processes the update request. Such as modifying the data item specified in the update request. In this embodiment, in the case of concurrent events, by judging whether an update request needs to be queued, if not queued, the database device can return a response to the application side that issued the update request in a timely manner without operating on the update request. Therefore, the processing efficiency of the database device can be improved; further, an indication indicating that concurrent operations have occurred can be carried in the corresponding returned message, so that the application side can be informed in time that concurrent operations have occurred, instead of waiting indefinitely, and take relevant actions measures, so the processing efficiency of the application side can be improved.

In Embodiment 1, the database device can judge whether to queue up the update request according to the information carried in the update request or the pre-configured information. In addition, the update request can further carry, or the pre-configured information can further Set the default or specified time information. The default or specified time is used to indicate that if the concurrent operation does not end after the default or specified time, it will no longer queue up and return the response message of the update request. Then step 15 when the database device queues up the update request, further execute the step of judging whether the update request needs to be queued according to the default or specified time, if the default or specified time does not end, then continue queuing, if When the default or specified time is over and the concurrent operation is not over yet, no queuing will be performed, and a response message to the update request will be returned.

Corresponding specific embodiments can refer to the following embodiments.

Fig. 2 is a schematic flow chart of Embodiment 2 of the method for processing shared data in the present invention. In this embodiment, AS accesses the fusion database through HSS FE, and HSS FE uses Lightweight Directory Access Protocol (Lightweight Directory Access Protocol, LDAP for short) to access the fusion database. database as an example. This example includes:

Step 21: After receiving the Sh interface update request (Sh-Update) sent by the first AS, the first HSS FE sends an update request (such as LDAP Modify) to the database device. The update request carries the data item to be modified, the version information of the data item (such as the business identifier and sequence number), and also carries the information indicating whether the concurrent operation of this update request is queued. This information can indicate that if there are other application parties When modifying the data item, the database needs to directly return a concurrent response instead of queuing in the database. It can also indicate that if there are concurrent operations, the database needs to queue the update request in the database. This information can be realized through extended LDAP parameters. The specific implementation of carrying extended parameters in the update request is as follows:

Mode 1: Carry the parameter by extending the control parameter (Control) in the LDAP protocol. Control is used to extend the function of LDAP without modifying the LDAP protocol itself. For example, a new LDAP Control (such as UrgentControl) can be added. This UrgentControl indicates that this operation does not allow concurrency. If the entry is being operated, a response message will be returned without queuing. The Urgent Control format is as follows.

Control::=SEQUENCE{

controlType LDAPOID, -- for example, set the value of LDAPOID to 1.3.6.1.1.13

criticality BOOLEAN DEFAULT FALSE,

controlValue OCTET STRING OPTIONAL--can be used to specify time

}

The above definition of UrgentControl is just an example, and other definition methods may also be adopted.

Method 2: The parameter is carried by extending the message body of the LDAP protocol. For example, a new parameter (such as Urgent) is added. Specifically, this parameter can be added in all update operations involved in LDAP. The update operations involved in LDAP include Add, Delete, and Modify operations. Taking the Modify operation as an example, the Modify format including this extended parameter is as follows:

ModifyRequest::＝[APPLICATION 6]SEQUENCE{

object LDAPDN,

changes SEQUENCE OF change SEQUENCE{

operation ENUMERATED{

add (0),

delete(1),

replace(2),

...},

modification PartialAttribute,

urgentIndication BOOLEAN,

urgentTime INTEGER}}

Among them, the above-mentioned urgentindication and urgenttime parameters are newly added, and are used to indicate whether the modification operation needs to be queued and specify a time.

The update request may further carry a default or specified time, and the default/specified time is used to indicate that if the concurrent operations within the time period are not completed, they will not be queued and a response message of the update request will be returned.

Step 22: If there is no update operation on the data item at this time, that is, the database device determines that there is no concurrent operation on the data item, then start a normal update operation on the data item.

Step 23: After receiving the Sh interface update request (Sh-Update) sent by the second AS, the second HSS FE sends an update request to the database device. Like the update request sent by the first HSS FE, the update request carries the data item to be modified, the version information of the data item, and information about whether a queue needs to be queued if concurrent operations occur in this request. In this embodiment, the information Indicates that if there are concurrent operations on the data item, the fusion database will directly return the concurrent processing response instead of queuing the modification command.

Step 24: After the database device receives the update request sent by the second HSS FE, if the database device is processing the update request sent by the first HSS FE at this time, the database determines that the data item is being processed.

Step 25: The database device returns an update response to the second HSS FE, which indicates that concurrent operations have occurred. It should be noted that the fusion database can also directly return a response message without specifying that concurrent operations occur.

In step 21, the extension of the request is realized, and in step 25, the response needs to be extended, and the extension of the response message can be realized in the following two ways:

Way 1: by extending the value of the result code (ResultCode) in the response message, that is, adding a new ResultCode value (eg ResultCode=Concurrent).

Method 2: By carrying a new control parameter Control (such as ConcurrenceControl) in the response message, the specific format of the newly added Control is as follows:

Control::＝SEQUENCE{

                                                                         , 

1.3.6.1.1.13

Criticality BOOLEAN DEFAULT FALSE,

    controlValue OCTET STRING OPTIONAL--can be used to indicate occurrence

concurrency

}

In the second manner, the ResultCode of the response message may be some form of error indication, such as operationsError.

This embodiment can make the AS clearly know that concurrent operations have occurred. If a time-consuming update request occurs concurrently, the AS does not have to wait, so the waiting time of the AS can be saved, which is conducive to improving the processing efficiency of the application side. When the database returns concurrent responses to the application in time, the processing efficiency of the database can be improved and the internal resources of the database can be saved. Furthermore, the fusion database can carry an indication indicating that a concurrent operation has occurred in the corresponding message returned, so that the application side can know that the concurrent operation has occurred in a timely manner, instead of waiting indefinitely, and take relevant measures, thus improving the application side. processing efficiency.

Step 26: The database device finishes processing the update request of the first HSS FE, and returns a success response (such as ResultCode=Success) to the first HSS FE.

In this embodiment, the flow of concurrent processing is shown by taking the update request carrying information about whether queuing is required as an example. At the same time, this embodiment takes the LDAP protocol as an example to show a specific implementation manner of the extension for carrying the above information. Through the process of this embodiment, system efficiency can be improved and system resources can be saved.

Fig. 3 is a schematic flow chart of Embodiment 3 of the method for processing shared data in the present invention. In this embodiment, AS directly accesses the fusion database and uses Extensible Markup Language Configuration Access Protocol (eXtensible Markup Language Configuration Access Protocol, XCAP for short) to access Take Fusion Database as an example. This example includes:

Step 31: The first AS sends an update request (XCAP Replace) to the database device. The update request will carry the data item to be modified as in the prior art, the version information of the data item (such as service identification and sequence number), and also carry the information of whether the concurrent operation is queued if this request occurs. In this embodiment This information indicates that if other application parties modify the data item, the database needs to directly return concurrent responses instead of queuing in the database.

Wherein, the information is implemented through an extended protocol, specifically, it can be implemented by adding relevant tags or identification parameters in all update operations involved in XCAP, and the update operations involved in XCAP include create/replace (PUT) and delete (DELETE) operations. For example, a label or identification parameter (such as Urgent) can be added in PUT or DELETE. The value of the label or identification parameter (such as UrgentIndication) is used to indicate whether to queue, and can further indicate the default or specified time. The province or specified time is used to indicate that if the concurrent operations within the time period have not ended, they will no longer be queued, and a response message to the update request will be returned.

Step 32: If there is no update operation on the data item at this time, that is, the database device determines that there is no concurrent operation on the data item, then start a normal update operation on the data item.

Step 33: The second AS sends an update request to the database device. Like the update request sent by the first AS, the update request carries the data item to be modified, the version information of the data item, and information about whether concurrent operations are queued if this request occurs. Concurrent operation of the item, the fusion database directly returns the concurrent processing response instead of queuing the modification command. It should be noted that the fusion database can also directly return a response message without specifying that concurrent operations occur.

Step 34: After the database device receives the update request sent by the second AS, if the database device is currently processing the update request sent by the first AS, the database determines that the data item is being processed.

Step 35: The database device returns a response to the second AS, which indicates that concurrent operations have occurred. For example, an HTTP 409 response using XCAP includes an error indication in the response's message body that a concurrent operation has occurred.

Compared with the synchronous error information returned in this case in the prior art, this embodiment can enable the AS to clearly know that a concurrent operation has occurred, and can further perform subsequent operations based on concurrency.

Step 36: the database device completes processing the update request of the first AS, and returns a success response to the first AS.

In this embodiment, the flow of concurrent processing is shown by taking the update request carrying information about whether queuing is required as an example. At the same time, this embodiment takes the XCAP protocol as an example to show a specific implementation manner of the extension for carrying the above information. Through the process of this embodiment, system efficiency can be improved and system resources can be saved.

Fig. 4 is a schematic flowchart of Embodiment 4 of the method for processing shared data according to the present invention. In this embodiment, the database device judges whether to queue up update requests based on pre-configured information as an example, and the application side in this embodiment can It is the HSS FE or AS in the above embodiment, or other network elements. This example includes:

Step 41: The first application sends an update request to the database device.

Step 42: The database device processes the update request.

Step 43: The second application sends an update request to the database device. The data item required to be updated by the update request is the same as the data item required to be updated by the first application side.

Step 44: The database device decides not to perform queuing processing on the update request according to the pre-configured information.

Among them, the specific implementation of the pre-configured information is as follows:

Way 1: Taking LDAP as an example, information about whether to queue corresponding update requests can be described in the LDAP data model (Schcma) when concurrent operations are generated for a specific data type or data item.

The information model in LDAP is similar to the object-oriented concept. In LDAP, each entry belongs to one or more object classes (ObjectClass), each ObjectClass is composed of multiple attribute types, and each attribute type has a corresponding syntax and matching rules; the definition of object classes and attribute types can use the concept of inheritance. When each entry is created, the object class to which it belongs must be defined, and the attribute value (Attribute) of the mandatory attribute type in the object class must be provided. In LDAP, one attribute type can correspond to multiple values. In LDAP, the object class, attribute type, syntax and matching rules are collectively referred to as Schema. Therefore, during configuration, the attributes Attribute, object class ObjectClass, directory information tree content rule DITContentRule, directory information tree structure rule DITStructureRule, and name form NameForm in the Schema can be extended to indicate that concurrency occurs for specific data types and data items. When an event occurs, whether to queue the corresponding update request. Taking the extension of Attribute as an example, the specific extension method is as follows (see RFC4512 for the format):

Extensions are: X-Urgent "0"

Among them, "Urgent" is the extension name, which indicates whether the update request for a certain data item or data type is queued when concurrency occurs; "0" is the time threshold (default or specified time), indicating that at the time indicated by the value If the concurrent operation in the segment is not completed, a concurrent message response will be returned. This value can be set to other numbers according to the configuration requirements.

Method 2: The configuration information can be stored in advance through configuration files, charts, etc. For example, parameters such as data name or data type or application type or operation type and whether they are queued can be recorded in configuration files or diagrams.

Step 45: The database device returns a response to the second application side, indicating that concurrency has occurred. Specifically, it can be: by extending the result code (ResultCode) value in the existing response message, that is, adding a new ResultCode value (such as ResultCode=Concurrent)

Step 46: After processing the update request of the first application party, the database device returns a success response (such as ResultCode=Success) to the first application party.

In this embodiment, the judgment is made according to the pre-configured information stored internally, and a corresponding processing flow is given. Through the process of this embodiment, the AS can clearly know that concurrent operations have occurred. If a relatively time-consuming update request occurs concurrently, the AS does not have to wait, so the waiting time of the AS can be saved, which is conducive to improving the application performance. When the database returns concurrent responses to the application in a timely manner, the processing efficiency of the database can be improved and the internal resources of the database can be saved. Furthermore, the fusion database can carry an indication indicating that a concurrent operation has occurred in the corresponding message returned, so that the application side can know that the concurrent operation has occurred in a timely manner, instead of waiting indefinitely, and take relevant measures, thus improving the application side. processing efficiency.

In this embodiment, information can also be carried in the update request as in the second and third embodiments, that is, the update request carries information indicating whether to queue the update request, and the database device is also pre-configured with preset information. At this time, the information indicating whether the update request needs to be queued if a concurrent operation occurs and the priority level of the pre-configured information can be set, and it is determined according to the priority level whether to judge whether the update request is based on the information in the update request or the preset information. The request is queued. For example, if the priority of the information carried in the update request is set higher than that of the preset information, the database will judge whether to queue according to the information carried in the update request. The setting of the priority level can be by setting a keyword (Priority) and corresponding content in the configuration file of the database, and determine the priority level according to the content in the keyword (for example, the priority level of the request is high).

The preset information in this embodiment may be information indicating whether an update request for a data item is queued. At this time, the judgment of whether to queue up can be directly performed according to the information, or the preset information in this embodiment may also include a time threshold. If If the concurrent operation does not end within the time threshold, the update request will not be queued, and a response will be returned directly, such as the first method in step 44 above.

In particular, in Embodiments 2 and 3, the application side can decide whether to queue for an update operation if there is concurrent generation according to its own needs. In this way, if a relatively time-consuming update operation occurs concurrently, the application side can know the concurrent information in time, and then can no longer wait, so as to save time and improve the processing efficiency of the application side; in the fourth embodiment, the database device can be based on It needs to decide whether to queue up the later update request when the concurrency of a certain data item occurs. In this way, if the update operation for a certain data item is complicated and time-consuming, it can return concurrent responses instead of queuing, so as to improve the processing efficiency of the database device and save internal resources of the database device.

Those of ordinary skill in the art can understand that all or part of the steps for realizing the above-mentioned method embodiments can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the It includes the steps of the above method embodiments; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk and other various media that can store program codes.

FIG. 5 is a schematic structural diagram of an embodiment of the database device of the present invention, including a receiving module 51 , a first judging module 52 , a second judging module 53 and a responding module 54 . The receiving module 51 is used to receive the update request for the data item sent by the application side, and send the update request to the first judging module 52; the first judging module 52 is used to judge whether there is Other applications are updating the data items targeted in the update request, and if so, send the update request to the second judging module 53; the second judging module 52 is used to judge that there are other applications in the first judging module 52 When the party performs an update operation on the data item, it is judged whether the update request needs to be queued, and if so, the operation of the response module 54 is triggered; queue, and return a response message of the update request to the application side, such as a response indicating that a concurrent operation has occurred.

Specifically, the receiving module 51 is used to receive an update request carrying information indicating whether the update request needs to be queued if concurrent operations occur; the second judgment module 53 is used to indicate whether the update request needs to be queued if concurrent operations occur according to the information It is judged whether the update request needs to be queued.

Alternatively, the database device may further include a preset module, which is used to store pre-configured preset information; at this time, the receiving module 51 may be used to receive an update request, and the second judging module 53 is used to It is judged whether the update request needs to be queued according to the preset information stored in the preset module.

The preset information stored in the preset module may be information indicating whether the update request for the data item needs to be queued; the second judging module 53 is used to judge whether the update request needs to be processed according to the preset information. queue. Alternatively, the preset information further includes a time threshold, and the second judging module 53 is specifically configured to determine that the data item is no longer updated when the other application side still performs an update operation on the data item after reaching the time threshold. Update requests are queued.

If the update request received by the device carries information indicating whether the update request needs to be queued, and pre-configured preset information is stored in the device, the device also includes a priority setting module, and the priority setting module uses The priority of setting the information carried in the update request and the preset information; the second judging module is specifically used to determine a judgment basis according to the priority, and judge whether the update request needs to be queued according to the judgment basis.

This embodiment may further include a queuing module, configured to perform queuing processing on the update request when the second judging module determines that the update request needs to be queued.

In this embodiment, in the case of concurrent events, by judging whether an update request needs to be queued, if not queued, the database device can promptly return a response indicating that a concurrent operation has occurred to the application side that issued the update request, without the need to Operation on the update request can improve the processing efficiency of the database device; at the same time, the application side can know in time that concurrent operations have occurred without waiting infinitely, so the processing efficiency of the application side can be improved.

FIG. 6 is a schematic structural diagram of Embodiment 1 of the system for processing shared data according to the present invention, including a first application device 61 and a first database device 62 . The first application-side device 61 is used to send an update request for a data item, and the update request carries information indicating whether the update request needs to be queued if concurrent operations occur; the first database device 62 is used to receive the update request from the first application-side device 61 Send the update request, and when it is judged that there are other application parties performing update operations on the data item, according to the information carried in the update request indicating whether the update request is queued if concurrent operations occur, it is judged whether it is necessary to update the data item The update request is queued, and when it is determined that the update request does not need to be queued, a response message of the update request is returned to the first application device 61, such as a response indicating that concurrent operations have occurred.

In this embodiment, in the case of concurrent events, the database device judges whether to queue or not according to the information carried in the update request sent by the application device. If there is no queue, the database device can promptly return an indication A response to a concurrent operation has occurred, and there is no need to operate on the update request, so the processing efficiency of the database device can be improved; at the same time, the application device can be informed of the occurrence of a concurrent operation in time without waiting indefinitely, so the application can be improved. The processing efficiency of the square device.

FIG. 7 is a schematic structural diagram of Embodiment 2 of the system for processing shared data according to the present invention, including a second application device 71 and a second database device 72 . The second application-side device 71 is used to send an update request for the data item; the second database device 72 is used to receive the update request sent by the second application-side device 71, and determine that there is another application-side update request for the data item When performing an update operation, it is judged according to pre-configured preset information whether the update request needs to be queued, and when it is judged that the update request does not need to be queued, the update request is returned to the second application device 71. Response message, such as a response indicating that a concurrent operation occurs, the preset information indicates whether a concurrent operation needs to be queued when a specific data type or data item occurs.

In this embodiment, in the case of concurrent events, the database device judges whether to queue or not according to the pre-configured information. If there is no queue, the database device can promptly return a response indicating that a concurrent operation has occurred to the application device that issued the update request. There is no need to operate on the update request, so the processing efficiency of the database device can be improved; at the same time, the application device can know in time that concurrent operations have occurred without waiting indefinitely, so the processing efficiency of the application device can be improved.

FIG. 8 is a schematic structural diagram of Embodiment 3 of the system for processing shared data according to the present invention, including a third application device 81 and a third database device 82 . This system combines the information of Embodiment 1 and Embodiment 2, that is, the third application device 81 is used to send an update request for data items, and the update request carries information indicating whether the update request needs to be queued if concurrent operations occur ; The third database device 82 is pre-configured with preset information, which indicates whether queuing is required when concurrent operations of a specific data type or data item occur. That is, there is a judgment basis in the update request, and the judgment basis is pre-configured, so the judgment basis needs to be determined; therefore, the third database device 82 needs to be further configured with the information in the update request and the priority level of the preset information. The third database device 82 is used to determine whether to queue up according to the priority level when it is determined that there are other application parties performing an update operation on the data item. Specifically, it may first determine the judgment basis according to the priority information, and then The above judgment basis judges whether the update request needs to be queued (for example, if the priority of the information in the update request is higher than the priority of the preset information, then judge whether to queue the update request according to the information in the update request, and vice versa ), and when it is determined that the update request does not need to be queued, return a response message of the update request to the second application-side device, such as a response indicating that a concurrent operation has occurred.

In this embodiment, in the case of concurrent events, the database device first determines the judgment basis according to the priority, and then judges whether to queue or not according to the determined judgment basis. If there is no queue, the database device can send the update request to the application device in time Returning a response indicating that a concurrent operation has occurred does not require an operation on the update request, so the processing efficiency of the database device can be improved; at the same time, the application device can be informed of the concurrent operation in time without waiting indefinitely, so it can Improve the processing efficiency of the application side device.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that: it still Modifications or equivalent replacements can be made to the technical solutions of the present invention, and these modifications or equivalent replacements cannot make the modified technical solutions deviate from the spirit and scope of the technical solutions of the present invention.

Claims (19)

1, a kind of method that shared data is handled is characterized in that, comprising:

Receive the update request that application side sends to data item;

Judge whether to exist other to use Founder described data item is being carried out concurrent operations;

If exist other to use Founder described data item is being carried out concurrent operations, judging whether and to rank to described update request;

If do not need described update request is ranked, then return the response message of described update request to described application side.

2, method according to claim 1 is characterized in that, carries in the described update request to show if this update request of concurrent operations takes place whether need the information of lining up; Described judge whether to rank to described update request specifically comprise: according to described show if take place this update request of concurrent operations whether the information of needs queuing judge whether that needs rank to described update request.

3, method according to claim 2, it is characterized in that: by the controlled variable of expansion Lightweight Directory Access Protocol, the message body of perhaps expanding Lightweight Directory Access Protocol carries describedly show if this update request of concurrent operations takes place whether need the information of lining up.

4, method according to claim 2 is characterized in that: carry describedly show if this update request of concurrent operations takes place whether need the information of lining up by the mode that increases label or identification parameter in XML (extensible Markup Language) configuration access agreement.

5, method according to claim 1, it is characterized in that, described judge whether to rank to described update request specifically comprise: judge whether that according to pre-configured information needs rank to described update request, whether described pre-configured information representation specific data type or data item generation concurrent operations need queuing.

6, method according to claim 5 is characterized in that: by the expansion Lightweight Directory Access Protocol data model in order to describe described pre-configured information; Perhaps, store described pre-configured information by the mode of configuration file or chart.

7, according to each described method of claim 1 to 6, it is characterized in that described method also comprises: if need rank, then to the processing of ranking of described update request to described update request.

8, method according to claim 7, it is characterized in that, further carry the temporal information of default or appointment in the described update request, perhaps, described pre-configured information further comprises the temporal information of default or appointment, described default or fixed time information shows if concurrent do not finish after operating in this default or fixed time, and the response message of update request is returned in then no longer queuing;

Accordingly, when described update request is ranked processing, further judge whether that according to described default or fixed time needs rank to described update request, if this is default or the fixed time finishes and described concurrent operations does not still finish, then no longer line up, return the response message of described update request.

9, method according to claim 1, it is characterized in that, carry in the described update request and show if this update request of concurrent operations takes place whether need the information of lining up, database to be provided with expression specific data type or data item generation concurrent operations in advance whether to need the information of lining up; Described method further comprises: described showing if the priority-level whether this update request of concurrent operations needs the information of lining up and described pre-configured information takes place is set;

Described judge whether to rank to described update request specifically comprise: judge whether that according to described priority-level needs rank to described update request.

10, according to claim 1 to 6 each, 8 or 9 described methods, it is characterized in that the described response message that returns described update request comprises: return to application side and show the response message that concurrent operations takes place.

11, method according to claim 10, it is characterized in that described returning to application side shows that the response message that concurrent operations takes place comprises: by the object code in the extended response message or in response message, carry new controlled variable and show the generation concurrent operations.

12, a kind of data library device is characterized in that, comprising:

Receiver module is used to receive the update request to data item that application side sends;

First judge module, be used for judging whether existing other use upright the update request that described receiver module is received at data item carry out concurrent operations;

Second judge module, other uses Founder when described data item is carried out concurrent operations to be used for judging existence at described first judge module, judges whether and need rank to described update request;

Respond module is used for judging at described second judge module and does not need described update request is ranked, and returns the response message of described update request to described application side.

13, device according to claim 12 is characterized in that:

Carry in the update request that described receiver module receives and show if this update request of concurrent operations takes place whether need the information of lining up;

Described second judge module is used for according to described showing if this update request of generation concurrent operations information whether needs are lined up judges whether needs described update request being ranked.

14, device according to claim 12 is characterized in that, also comprises:

Presetting module is used to store pre-configured information, and whether described pre-configured information representation specific data type or data item generation concurrent operations need queuing;

Described second judge module is used for judging whether that according to the pre-configured information that described presetting module is stored needs rank to described update request.

15, device according to claim 14 is characterized in that:

Show if this update request of concurrent operations takes place whether need the information of lining up if carry in the described update request, then this device comprises that also priority is provided with module, is used for being provided with that update request carries shows if the priority-level whether this update request of concurrent operations needs the information of lining up and pre-configured information takes place; Described second judge module specifically is used for judging whether that according to described priority-level needs rank to described update request.

16, device according to claim 12 is characterized in that, also comprises: queue module is used for judging need rank to described update request the time at described second judge module, to the processing of ranking of described update request.

17, a kind of system that shared data is handled is characterized in that, comprising:

First application side's device is used to send the update request to data item, carries in the described update request to show if this update request of concurrent operations takes place whether need the information of lining up;

First data library device, be used for judging when existing other application side that described data item is carried out concurrent operations, according to showing of carrying in the described update request if take place this update request of concurrent operations whether the information of needs queuing judge whether that needs rank to described update request, and judging when not needing described update request ranked, return the response message of described update request to described first application side's device.

18, a kind of system that shared data is handled is characterized in that, comprising:

Second application side's device is used to send the update request to data item;

Second data library device, be used for judging when existing other application side that described data item is carried out concurrent operations, judge whether that according to pre-configured information needs rank to described update request, and judging when not needing described update request ranked, return the response message of described update request to described second application side's device, whether described pre-configured information representation specific data type or data item generation concurrent operations need queuing.

19, a kind of system that shared data is handled is characterized in that, comprising:

The 3rd application side's device is used to send the update request to data item, carries in the described update request to show if this update request of concurrent operations takes place whether need the information of lining up;

The 3rd data library device, be provided with in advance and represent whether specific data type or data item generation concurrent operations need the presupposed information of lining up, and whether showing of carrying in the update request that receives needs the information of lining up and the priority-level of described presupposed information if this update request of concurrent operations takes place, be used for judging when existing other application side that described data item is carried out concurrent operations, judge whether that according to described priority-level needs rank to described update request, and judging when not needing described update request ranked, return the response message of described update request to described the 3rd application side's device.

Images