File locking method, system and storage medium based on adaptive optimistic locking

Abstract

The present application relates to a file locking method, system, electronic device and storage medium based on adaptive optimistic lock, wherein the method includes: an access request acquisition step, which is used to receive a file access request from a client and cache a lock request corresponding to the access request through a waiting queue; a lock conflict judgment step, which is used to obtain the head lock request in the waiting queue when a resource release occurs for an allocated lock, and judge whether the head lock request conflicts with the range of existing lock requests in the file corresponding to the head lock request; a request processing step, which is used to grant the resources corresponding to the head lock request when there is no conflict between the head lock request and the lock request already existing in the file; on the contrary, the released resources are obtained according to whether the conflict range between the head lock request and the existing lock request belongs to the extended range. Through the present application, the problem of reduced lock request efficiency when the optimistic lock mechanism faces multiple processes interleaving access to different ranges of files is solved, and the request processing efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a file locking method, system, electronic device and computer-readable storage medium based on adaptive optimistic locking. Background Art

[0002] When multiple processes access the same file, in order to avoid data confusion caused by concurrent operations, the files that need to be operated are usually locked. However, if different processes access different intervals of data in the file, the overhead of locking the entire file is relatively high. In this case, byte range locks are needed to reduce conflicts. Range locks lock a certain area in the file. Multiple range locks can be allowed for the same file, thereby improving the concurrency of multiple processes accessing the same file at the same time. However, when a single process accesses different areas of the same file multiple times, byte range locks are not as efficient as file locks.

[0003] Currently, optimistic locking mechanism is used to solve the problem of low efficiency of range locking when a single process accesses different areas of the same file multiple times. The main idea of ​​optimistic locking mechanism is as follows Figure 1 As shown in the figure: when receiving a request to access a certain area of ​​the file, the requesting process is given the maximum range lock including the requested area according to the already allocated lock range. In other words, the requesting process does not get the exact range of the requested lock, but covers the requested lock range without conflicting with other existing range locks, and at the same time extends the maximum range continuous with the requested range.

[0004] The existing technology is very effective when a single process accesses different ranges of a file multiple times. However, if multiple processes need to interleave access to different ranges of a file, this optimistic locking mechanism can easily cause conflicts, requiring a large number of lock release operations, which greatly reduces the efficiency of lock requests and causes increased network load and operation delays. Summary of the invention

[0005] Embodiments of the present application provide a file locking method, system, electronic device, and computer-readable storage medium based on adaptive optimistic locking, so as to at least solve the problem of reduced lock request efficiency when the optimistic locking mechanism faces multiple processes interleavingly accessing different ranges of a file.

[0006] In a first aspect, an embodiment of the present application provides a file locking method based on adaptive optimistic locking, comprising:

[0007] An access request acquisition step, for receiving a file access request from a client and caching a lock request corresponding to the access request through a waiting queue;

[0008] A lock conflict judgment step, for obtaining a head lock request in the waiting queue when a resource release occurs for an allocated lock, and judging whether the head lock request conflicts with a range of existing lock requests in a file corresponding to the head lock request;

[0009] The request processing step is used to grant the resources corresponding to the head lock request when there is no conflict between the head lock request and the lock request already existing in the file; otherwise, the resources are released according to whether the conflict range between the head lock request and the existing lock request belongs to the extended range.

[0010] Based on the above steps, the embodiment of the present application caches all lock requests through the waiting queue, and takes the lock request at the head of the waiting queue to determine whether it conflicts with the existing lock request, thereby solving the problem of inefficient lock request processing caused by a large number of lock release operations when multiple processes access files in an interlaced manner, reducing operation delays and improving request processing efficiency.

[0011] In some embodiments, the request processing step further comprises:

[0012] A resource granting step is used to grant resources corresponding to the head-of-line lock request when the head-of-line lock request does not conflict with the existing lock request in the file;

[0013] An extension range determination step is used to determine whether the conflict range between the head-of-queue lock request and the existing lock request belongs to an extension range;

[0014] The resource release step is used to lock the extended range according to the head lock request if the conflict range belongs to the extended range, and remove the head lock request from the waiting queue when the client to which the existing lock request belongs releases the extended range resources, that is, unlocks the resources of the extended range; otherwise, the head lock request waits for the existing lock request to release the resources and executes the lock conflict judgment step.

[0015] In some embodiments, the step of requesting resource grant further comprises:

[0016] A unique lock request processing step, used to determine whether the head lock request is the only lock request in the waiting queue, if the head lock request is the only lock request in the waiting queue, then locking the extended range of the resource corresponding to the head lock request according to the optimistic locking mechanism and removing the head lock request from the waiting queue;

[0017] A client lock request acquisition step, for traversing the lock requests in the waiting queue in order and acquiring the lock request of the client if the head lock request is not the only lock request in the waiting queue;

[0018] A lock request processing step, for locking the resources corresponding to the head lock request according to the optimistic locking mechanism and removing the head lock request from the waiting queue if the lock request of the client in the waiting queue is the head lock request, that is, there is no other lock request from the client in the waiting queue. It is worth noting that at this time, the extended range of the resources corresponding to the head lock request is not locked;

[0019] The extended lock request processing step is used to perform lock request processing at the position of the waiting queue according to the at least two lock requests if the lock request of the client in the waiting queue includes at least two lock requests including the head lock request, that is, there are other lock requests from the client in the waiting queue.

[0020] In some embodiments, the extended lock request processing step further includes:

[0021] The lock request position acquisition step is used to determine whether the at least two lock requests are located at the preset position of the waiting queue. If the at least two lock requests are located at the preset position of the waiting queue, the extended range of the resources corresponding to the head lock request is locked according to the optimistic locking mechanism and the head lock request is moved out of the waiting queue; otherwise, the resources corresponding to the head lock request are locked and the head lock request is moved out of the waiting queue. It is worth noting that the extended range of the resources corresponding to the head lock request is not locked at this time.

[0022] Based on the above steps, a judgment rule for determining the locking method of the head-of-line lock request and multiple ways of locking the head-of-line lock request are provided. On the one hand, the optimistic lock is retained as much as possible to lock the extended range of the lock request to retain its advantage in single-threaded access; on the other hand, a non-optimistic lock form is used to directly lock the request to avoid conflicts with other lock requests, thereby further improving the request processing efficiency when multiple processes access files in an interleaved manner.

[0023] In some embodiments, the preset position is a position range of the first quarter of the waiting queue.

[0024] In some of the embodiments, the range indexing of the embodiments of the present application is implemented using a B+ tree as a data structure, and the range search is further optimized by utilizing the characteristics that the leaf nodes of the B+ tree contain all keyword information and are sequentially linked. The B+ tree is a tree data structure that is commonly used in databases and operating system file systems. The characteristic of the B+ tree is that it can keep data stable and orderly, and its insertion and modification have a relatively stable logarithmic time complexity.

[0025] In a second aspect, an embodiment of the present application provides a file locking system based on adaptive optimistic locking, including:

[0026] An access request acquisition module, used for receiving a file access request from a client and caching a lock request corresponding to the access request through a waiting queue;

[0027] A lock conflict judgment module is used to obtain the head lock request in the waiting queue when the resource of the allocated lock is released, and judge whether the head lock request conflicts with the range of the existing lock request in the file corresponding to the head lock request;

[0028] The request processing module is used to grant the resources corresponding to the head lock request when there is no conflict between the head lock request and the existing lock request in the file; otherwise, it is used to determine whether the conflict range between the head lock request and the existing lock request belongs to the extended range and obtain the released resources.

[0029] Based on the above module, the embodiment of the present application caches all lock requests through the waiting queue, and takes the lock request at the head of the waiting queue to determine whether it conflicts with the existing lock request, thereby solving the problem of inefficient lock request processing caused by a large number of lock release operations when multiple processes access files in an interlaced manner, reducing operation delays and improving request processing efficiency.

[0030] In some embodiments, the request processing module further includes:

[0031] A resource granting module is used to grant resources corresponding to the head lock request when the head lock request does not conflict with the existing lock request in the file;

[0032] An extension range determination module, used to determine whether the conflict range between the head-of-queue lock request and the existing lock request belongs to an extension range;

[0033] A resource release module is used to lock the corresponding resources according to the head lock request if the conflict range belongs to the extended range, when the client to which the existing lock request belongs releases the resources of the extended range, that is, when the resources of the extended range are unlocked, and move the head lock request out of the waiting queue; otherwise, the head lock request waits for the existing lock request to release the resources and enters the lock conflict judgment module.

[0034] In some embodiments, the resource granting request module further comprises:

[0035] A unique lock request processing module, used to determine whether the head lock request is the only lock request in the waiting queue, and if the head lock request is the only lock request in the waiting queue, lock the extended range of the resource corresponding to the head lock request according to the optimistic lock mechanism and remove the head lock request from the waiting queue;

[0036] A client lock request acquisition module, configured to sequentially traverse the lock requests in the waiting queue and acquire the lock request of the client if the head lock request is not the only lock request in the waiting queue;

[0037] A lock request processing module, for locking the resources corresponding to the head lock request and removing the head lock request from the waiting queue according to an optimistic locking mechanism if the lock request of the client in the waiting queue is the head lock request, that is, there are no other lock requests from the client in the waiting queue. It is worth noting that at this time, the extended range of the resources corresponding to the head lock request is not locked;

[0038] The extended lock request processing module is used to perform lock request processing at the position of the waiting queue according to the at least two lock requests if the lock request of the client in the waiting queue includes at least two lock requests of the head lock request, that is, there are other lock requests from the client in the waiting queue.

[0039] Based on the above module, the embodiment of the present application determines the locking method for the head-of-queue lock request by judging whether the request to be processed in the waiting queue belongs to the same process as the current head-of-queue lock request, that is, it is a lock request from the same client.

[0040] In some embodiments, the extended lock request processing module further includes:

[0041] A lock request position acquisition module is used to determine whether the at least two lock requests are located at the preset position of the waiting queue. If the at least two lock requests are located at the preset position of the waiting queue, then according to the optimistic locking mechanism, the extended range of the resources corresponding to the head lock request is locked and the head lock request is moved out of the waiting queue; otherwise, the resources corresponding to the head lock request are locked and the head lock request is moved out of the waiting queue. It is worth noting that at this time, the extended range of the resources corresponding to the head lock request is not locked.

[0042] Based on the above modules, an embodiment of the present application provides a judgment-based prediction rule for determining the locking method of the head-of-line lock request and multiple methods of locking the head-of-line lock request. On the one hand, the optimistic lock is retained as much as possible to lock the extended range of the lock request to retain its advantages in single-threaded access; on the other hand, by directly locking the requested non-optimistic lock form to avoid conflicts with other lock requests, the request processing efficiency is further improved when multiple processes access files in an interleaved manner.

[0043] In some embodiments, the preset position is a position range of the first quarter of the waiting queue.

[0044] In some of the embodiments, the range indexing of the embodiments of the present application is implemented using a B+ tree as a data structure, and the range search is further optimized by utilizing the characteristics that the leaf nodes of the B+ tree contain all keyword information and are sequentially linked. The B+ tree is a tree data structure that is commonly used in databases and operating system file systems. The characteristic of the B+ tree is that it can keep data stable and orderly, and its insertion and modification have a relatively stable logarithmic time complexity.

[0045] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the file locking method based on adaptive optimistic locking as described in the first aspect above is implemented.

[0046] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the file locking method based on adaptive optimistic locking as described in the first aspect above.

[0047] Compared with the related art, the file locking method and system based on adaptive optimistic locking provided by the embodiment of the present application not only solves the problem of low efficiency of the prior art solution when multiple processes access files in an interleaved manner, but also retains its advantages when accessed by a single thread.

[0048] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0050] Figure 1 is a schematic diagram of an optimistic locking mechanism according to the related art;

[0051] Figure 2 It is a flowchart of a file locking method based on adaptive optimistic locking according to an embodiment of the present application;

[0052] Figure 3 It is a schematic diagram of a step-by-step flow chart of a file locking method based on adaptive optimistic locking according to an embodiment of the present application;

[0053] Figure 4 It is a flowchart of a file locking method based on adaptive optimistic locking according to a preferred embodiment of the present application;

[0054] Figure 5is a structural block diagram of a file locking system based on adaptive optimistic locking according to an embodiment of the present application;

[0055] Figure 6 It is a substructure block diagram of a file locking system based on adaptive optimistic locking according to an embodiment of the present application. Description of the drawings:

[0057] 1. Access request acquisition module; 2. Lock conflict judgment module; 3. Request processing module;

[0058] 31. Resource grant request module; 32. Extension range determination module; 33. Resource release module;

[0059] 311. unique lock request processing module; 312. client lock request acquisition module;

[0060] 313. Lock request processing module; 314. Extended lock request processing module;

[0061] 3141. Lock request position acquisition module. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0063] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complicated and lengthy, for ordinary technicians in this field related to the content disclosed in this application, some changes in design, manufacturing or production based on the technical content disclosed in this application are just conventional technical means, and should not be understood as insufficient content disclosed in this application.

[0064] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0065] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantitative limitation, and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there may be three relationships, for example, "A and / or B" can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects before and after are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0066] In order to solve the problem that the optimistic locking mechanism is applied to file access and multiple processes interleave to access different ranges of the file, it is easy to cause conflicts, the embodiment of the present application provides a file locking method based on adaptive optimistic locking, Figure 2 is a flowchart of a file locking method based on adaptive optimistic locking according to an embodiment of the present application, Figure 3 is a schematic diagram of a step-by-step process of a file locking method based on adaptive optimistic locking according to an embodiment of the present application, such as Figure 2-3 As shown, the process includes the following steps:

[0067] An access request acquisition step S1 is used to receive a file access request from a client and cache a lock request corresponding to the access request through a waiting queue;

[0068] The lock conflict judgment step S2 is used to obtain the head lock request in the waiting queue when the resource of the allocated lock is released, and judge whether the head lock request conflicts with the range of the existing lock request in the file corresponding to the head lock request;

[0069] The request processing step S3 is used to grant the resources corresponding to the head lock request when there is no conflict between the head lock request and the lock request already existing in the file; otherwise, the resources are released according to whether the conflict range between the head lock request and the existing lock request belongs to the extended range.

[0070] Based on the above steps, the embodiment of the present application caches all lock requests through a waiting queue, and takes the lock request at the head of the waiting queue to determine whether it conflicts with an existing lock request, thereby solving the problem of inefficient lock request processing caused by a large number of lock release operations when multiple processes access files in an interleaved manner, reducing operation delays and improving request processing efficiency.

[0071] In some embodiments, the request processing step S3 further comprises:

[0072] The resource granting request step S31 is used to grant the resources corresponding to the head lock request when there is no conflict between the head lock request and the existing lock request in the file;

[0073] An extension range determination step S32 is used to determine whether the conflict range between the head-of-queue lock request and the existing lock request belongs to the extension range;

[0074] The resource release step S33 is used to lock the extended range if the conflict range belongs to the extended range. When the client to which the existing lock request belongs releases the extended range resources, that is, when the resources of the extended range are unlocked, the extended range is locked according to the head lock request and the head lock request is removed from the waiting queue; otherwise, the head lock request waits for the existing lock request to release the resources and executes the lock conflict judgment step.

[0075] In some embodiments, the resource grant request step S31 further includes:

[0076] The unique lock request processing step S311 is used to determine whether the head lock request is the only lock request in the waiting queue. If the head lock request is the only lock request in the waiting queue, the extended range of the resource corresponding to the head lock request is locked according to the optimistic locking mechanism and the head lock request is removed from the waiting queue.

[0077] The client lock request acquisition step S312 is used to traverse the lock requests in the waiting queue in order and acquire the client lock request if the head lock request is not the only lock request in the waiting queue;

[0078] The lock request processing step S313 is used to lock the resources corresponding to the head lock request according to the optimistic locking mechanism and remove the head lock request from the waiting queue if the lock request from the client in the waiting queue is the head lock request, that is, there is no other lock request from the client in the waiting queue. It is worth noting that at this time, the extended range of the resources corresponding to the head lock request is not locked;

[0079] The extended lock request processing step S314 is used to process the lock request at the position in the waiting queue according to the at least two lock requests if the lock request from the client in the waiting queue includes at least two lock requests at the head of the queue, that is, there are other lock requests from the client in the waiting queue.

[0080] In some embodiments, the extended lock request processing step S314 further includes:

[0081] The lock request position acquisition step S3141 is used to determine whether at least two lock requests are located at the preset position of the waiting queue. If at least two lock requests are located at the preset position of the waiting queue, the extended range of the resources corresponding to the head lock request of the team is locked according to the optimistic locking mechanism and the head lock request of the team is moved out of the waiting queue; otherwise, the resources corresponding to the head lock request of the team are locked and the head lock request of the team is moved out of the waiting queue. It is worth noting that the extended range of the resources corresponding to the head lock request of the team is not locked at this time. Optionally, the preset position is the position range of the first quarter of the waiting queue.

[0082] In some of the embodiments, the range indexing of the embodiments of the present application is implemented using a B+ tree as a data structure.

[0083] Based on the above steps, a judgment rule for determining the locking method of the head-of-line lock request and multiple ways of locking the head-of-line lock request are provided. On the one hand, the optimistic lock is retained as much as possible to lock the extended range of the lock request to retain its advantage in single-threaded access; on the other hand, a non-optimistic lock form is used to directly lock the request to avoid conflicts with other lock requests, thereby further improving the request processing efficiency when multiple processes access files in an interleaved manner.

[0084] The embodiments of the present application are described and illustrated below through preferred embodiments.

[0085] Figure 4 is a flowchart of a file locking method based on adaptive optimistic locking according to a preferred embodiment of the present application. Figure 4 As shown, the file locking method based on adaptive optimistic locking includes the following steps:

[0086] Step S401: The client sends an access request and puts the lock request into a waiting queue.

[0087] Step S402, when the resource of the allocated lock is released, the request at the head of the waiting queue is taken, that is, the head lock request, and the head lock request is judged for conflict with the existing lock request range. If the head lock request conflicts with the existing lock request, go to step S403, otherwise go to step S404.

[0088] Step S403, determine whether the conflict range between the head-of-team lock request and the existing lock request belongs to the extended range. If it is an extended range conflict, the client to which the existing lock request belongs needs to release the lock of the extended range, and then allocate a lock for the current head-of-team lock request, and move the head-of-team lock request out of the waiting queue. The lock request is successfully processed once and the process ends; if it is not an extended range conflict, let the current head-of-team lock request wait for the release of the existing lock resources and go to step S402.

[0089] Step S404: if the head lock request does not conflict with the existing lock request, lock resources need to be allocated to the client request. Specifically, first determine whether the waiting queue contains only the current head lock request. If so, go to step S405; otherwise, go to step S406.

[0090] Step S405, if there are no other requests in the waiting queue, the optimistic locking mechanism is used to extend the range of locking, and the request at the head of the waiting queue is removed. The lock request is successfully processed once, and the process ends.

[0091] Step S406, if there are other requests in the waiting queue, search from front to back for other requests from the same client as the current head lock request in the waiting queue. If a request that meets the condition is found, go to step S407, otherwise go to step S408.

[0092] Step S407, determine whether the request that meets the conditions is located in the first quarter of the waiting queue. If so, lock the extended range according to the optimistic locking mechanism; if not, lock the range of the head lock request normally without expanding the range. Remove the request at the head of the waiting queue, successfully process a lock request, and the process ends.

[0093] Step S408: If there are no other requests that meet the conditions in the queue, the lock is normally added according to the lock request range without expanding the range, and the request at the head of the waiting queue is removed. Once the lock request is successfully processed, the process ends.

[0094] It should be noted that the steps shown in the above process or the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0095] This embodiment also provides a file locking system based on adaptive optimistic locking, which is used to implement the above embodiments and preferred implementations, and will not be repeated here. As used below, the terms "module", "unit", "subunit", etc. can implement a combination of software and / or hardware for a predetermined function. Although the system described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0096] Figure 5 is a structural block diagram of a file locking system based on adaptive optimistic locking according to an embodiment of the present application, Figure 6 is a substructure block diagram of a file locking system based on adaptive optimistic locking according to an embodiment of the present application, such as Figure 5-6 As shown, the system includes:

[0097] An access request acquisition module 1 is used to receive a file access request from a client and cache a lock request corresponding to the access request through a waiting queue;

[0098] The lock conflict judgment module 2 is used to obtain the head lock request in the waiting queue when the resource of the allocated lock is released, and judge whether the head lock request conflicts with the range of the existing lock request in the file corresponding to the head lock request;

[0099] Request processing module 3 is used to grant resources corresponding to the head lock request when there is no conflict between the head lock request and the existing lock request in the file; otherwise, it is used to determine whether the conflict range between the head lock request and the existing lock request belongs to the extended range and obtain the released resources.

[0100] Based on the above module, the embodiment of the present application caches all lock requests through a waiting queue, and takes the lock request at the head of the waiting queue to determine whether it conflicts with an existing lock request, thereby solving the problem of inefficient lock request processing caused by a large number of lock release operations when multiple processes access files in an interleaved manner, reducing operation delays and improving request processing efficiency.

[0101] Among them, the request processing module 3 further includes: a request resource assignment module 31, which is used to assign the resources corresponding to the head lock request when there is no conflict between the head lock request and the existing lock request in the file; an extended range judgment module 32, which is used to judge whether the conflict range between the head lock request and the existing lock request belongs to the extended range; a resource release module 33, which is used to lock the corresponding resources according to the head lock request if the conflict range belongs to the extended range, when the client to which the existing lock request belongs releases the extended range resources, that is, when the extended range resources are unlocked; otherwise, the head lock request waits for the existing lock request to release the resources and enters the lock conflict judgment module 2.

[0102] The resource request granting module 31 further includes: a unique lock request processing module 311, which is used to determine whether the head lock request is the only lock request in the waiting queue. If the head lock request is the only lock request in the waiting queue, the extended range of the resource corresponding to the head lock request is locked according to the optimistic lock mechanism and the head lock request is removed from the waiting queue; a client lock request acquisition module 312, which is used to traverse the lock requests in the waiting queue in order and acquire the lock request of the client if the head lock request is not the only lock request in the waiting queue; a lock request processing module 313, which is used to determine whether the head lock request is the only lock request in the waiting queue. The lock request of the client end is the head lock request, that is, there are no other lock requests from the client in the waiting queue, then according to the optimistic locking mechanism, the resources corresponding to the head lock request are locked and the head lock request is removed from the waiting queue. It is worth noting that at this time, the extended range of the resources corresponding to the head lock request is not locked; the extended lock request processing module 314 is used for if the lock request of the client in the waiting queue is at least two lock requests including the head lock request, that is, there are other lock requests from the client in the waiting queue, then the lock request is processed according to the position of the waiting queue according to the at least two lock requests. Specifically, the extended lock request processing module 314 further includes: a lock request position acquisition module 3141, which is used to determine whether at least two lock requests are located at the preset position of the waiting queue. If at least two lock requests are located at the preset position of the waiting queue, the extended range of the resources corresponding to the head lock request is locked according to the optimistic locking mechanism and the head lock request is removed from the waiting queue; otherwise, the resources corresponding to the head lock request are locked and the head lock request is removed from the waiting queue. It is worth noting that at this time, the extended range of the resources corresponding to the head lock request is not locked. Optionally, the preset position is a position range of the first quarter of the waiting queue. Specifically, the range indexing in the embodiment of the present application is implemented using a B+ tree as a data structure.

[0103] Based on the above module, by judging whether the request to be processed in the waiting queue belongs to the same process as the current head lock request, that is, whether it is a lock request from the same client, the locking method of the head lock request is determined. The system also provides a prediction rule based on judgment to determine the locking method of the head lock request and multiple ways to lock the head lock request. On the one hand, the optimistic lock is retained as much as possible to lock the extended range of the lock request to retain its advantages in single-threaded access; on the other hand, the non-optimistic lock form is directly locked for the request to avoid conflicts with other lock requests, further improving the request processing efficiency when multiple processes interleave to access files.

[0104] Based on the above system, the embodiment of the present application needs to enter a waiting queue for all lock requests first, and take the head lock request to determine whether it conflicts with the existing lock request. If the head lock request does not conflict with the existing lock request, it is necessary to grant the client a corresponding range lock, and adopt an adaptive optimistic lock mechanism, such as recording the head lock request as Q1, the current requesting client as A, and searching the waiting queue from front to back for the request of the same client A, recording the first request found as Q2, and judging whether the position of request Q2 in the waiting queue is in the first quarter, if so, it means that the same client may issue a lock request again in a short time, and the head lock request Q1 is locked with an extended range according to the optimistic lock mechanism, and if there are no other requests in the waiting queue, the extended range is also locked according to the optimistic lock method; if no request is found for the same client A or the request is not located in the first quarter of the queue, it means that the recent requests are all other processes, and in order to avoid conflicts, the lock is normally locked according to the range of the lock request, and the range is not expanded.

[0105] If the head lock request conflicts with an existing lock request, determine whether the conflict range belongs to the extended range. If it is an extended range conflict, the client to which the existing lock belongs needs to release the extended range lock, then allocate a lock for the current head lock request, and remove the head lock request from the waiting queue. If it is not an extended range conflict, wait for the existing lock resource to be released.

[0106] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0107] In addition, combined Figure 2-3 The file locking method based on adaptive optimistic locking in the embodiment of the present application described can be implemented by an electronic device. The electronic device may include a processor and a memory storing computer program instructions. Specifically, the processor may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiment of the present application.

[0108] Among them, the memory may include a large capacity memory for data or instructions. By way of example and not limitation, the memory may include a hard disk drive (HDD), a floppy disk drive, a solid state drive (SSD), a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include a removable or non-removable (or fixed) medium. Where appropriate, the memory may be inside or outside the data processing device. In a specific embodiment, the memory is a non-volatile memory. In a specific embodiment, the memory includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, PROM for short), an erasable PROM (Erasable ProgrammableRead-Only Memory, EPROM for short), an electrically erasable PROM (Electrically Erasable ProgrammableRead-Only Memory, EEPROM for short), an electrically alterable ROM (Electrically Alterable Read-Only Memory, EAROM for short) or a flash memory (FLASH) or a combination of two or more of these. Under appropriate circumstances, the RAM can be a static random access memory (SRAM) or a dynamic random access memory (DRAM), wherein the DRAM can be a fast page mode dynamic random access memory (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0109] The memory may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor.

[0110] The processor implements any one of the file locking methods based on adaptive optimistic locking in the above embodiments by reading and executing computer program instructions stored in the memory.

[0111] In addition, in combination with the file locking method based on adaptive optimistic locking in the above embodiments, the present application embodiment can provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by the processor, any one of the file locking methods based on adaptive optimistic locking in the above embodiments is implemented.

[0112] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0113] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A file locking method based on adaptive optimistic locking, characterized in that: include: An access request acquisition step, for receiving a file access request from a client and caching a lock request corresponding to the access request through a waiting queue; A lock conflict judgment step, for obtaining a head lock request in the waiting queue when a resource release occurs for an allocated lock, and judging whether the head lock request conflicts with a range of existing lock requests in a file corresponding to the head lock request; A request processing step, for granting resources corresponding to the head-of-line lock request when there is no conflict between the head-of-line lock request and the lock request already existing in the file; On the contrary, the resources are released according to whether the conflict range between the head-of-line lock request and the existing lock request belongs to the extended range. The request processing step further includes: a request resource granting step, which is used to grant resources corresponding to the head lock request when the head lock request has no conflict with the existing lock request in the file, and the request resource granting step further includes: The extended lock request processing step is used for performing lock request processing according to the position of the waiting queue according to the at least two lock requests if the lock request of the client in the waiting queue is at least two lock requests including the head lock request, that is, there are other lock requests from the client in the waiting queue. The extended lock request processing step further includes: A lock request position acquisition step is used to determine whether the at least two lock requests are located at the preset position of the waiting queue. If the at least two lock requests are located at the preset position of the waiting queue, the extended range of the resources corresponding to the head lock request is locked according to the optimistic locking mechanism and the head lock request is moved out of the waiting queue; otherwise, the resources corresponding to the head lock request are locked and the head lock request is moved out of the waiting queue.

2. The file locking method based on adaptive optimistic locking according to claim 1, characterized in that: The request processing step further comprises: An extension range determination step is used to determine whether the conflict range between the head-of-queue lock request and the existing lock request belongs to an extension range; The resource release step is used to lock the extended range according to the head lock request and remove the head lock request from the waiting queue if the conflict range belongs to the extended range when the client to which the existing lock request belongs releases the extended range resources; otherwise, the head lock request waits for the existing lock request to release the resources and executes the lock conflict judgment step.

3. The file locking method based on adaptive optimistic locking according to claim 2, characterized in that: The step of requesting resource granting further comprises: A unique lock request processing step, used to determine whether the head lock request is the only lock request in the waiting queue, if the head lock request is the only lock request in the waiting queue, then locking the extended range of the resource corresponding to the head lock request according to the optimistic locking mechanism and removing the head lock request from the waiting queue; A client lock request acquisition step, for traversing the lock requests in the waiting queue in order and acquiring the lock request of the client if the head lock request is not the only lock request in the waiting queue; The lock request processing step is used to lock the resources corresponding to the head lock request according to the optimistic locking mechanism and remove the head lock request from the waiting queue if the lock request of the client in the waiting queue is the head lock request.

4. A file locking system based on adaptive optimistic locking, characterized in that: include: An access request acquisition module, used for receiving a file access request from a client and caching a lock request corresponding to the access request through a waiting queue; A lock conflict judgment module is used to obtain the head lock request in the waiting queue when the resource of the allocated lock is released, and judge whether the head lock request conflicts with the range of the existing lock request in the file corresponding to the head lock request; A request processing module, configured to grant resources corresponding to the head-of-line lock request when there is no conflict between the head-of-line lock request and the lock request already existing in the file; Otherwise, it is determined whether the conflict range between the head-of-line lock request and the existing lock request belongs to the extended range and the released resources are obtained. The request processing module further includes: a request resource granting module, which is used to grant resources corresponding to the head lock request when the head lock request has no conflict with the existing lock request in the file; the request resource granting module further includes: The extended lock request processing module is used for performing lock request processing according to the position of the at least two lock requests in the waiting queue if the lock request of the client in the waiting queue is at least two lock requests including the head lock request, that is, there are other lock requests from the client in the waiting queue. The extended lock request processing module further includes: A lock request position acquisition module is used to determine whether the at least two lock requests are located at the preset position of the waiting queue. If the at least two lock requests are located at the preset position of the waiting queue, the extended range of the resources corresponding to the head lock request is locked according to the optimistic locking mechanism and the head lock request is moved out of the waiting queue; otherwise, the resources corresponding to the head lock request are locked and the head lock request is moved out of the waiting queue.

5. The file locking system based on adaptive optimistic locking according to claim 4, characterized in that: The request processing module further comprises: An extension range determination module, used to determine whether the conflict range between the head-of-queue lock request and the existing lock request belongs to an extension range; A resource release module is used to lock the corresponding resources according to the head lock request and move the head lock request out of the waiting queue if the conflict range belongs to the extended range and when the client to which the existing lock request belongs releases the extended range resources; otherwise, the head lock request waits for the existing lock request to release the resources and enters the lock conflict judgment module.

6. The file locking system based on adaptive optimistic locking according to claim 5, characterized in that: The resource granting request module further comprises: A unique lock request processing module, used to determine whether the head lock request is the only lock request in the waiting queue, and if the head lock request is the only lock request in the waiting queue, lock the extended range of the resource corresponding to the head lock request according to the optimistic lock mechanism and remove the head lock request from the waiting queue; A client lock request acquisition module, configured to sequentially traverse the lock requests in the waiting queue and acquire the lock request of the client if the head lock request is not the only lock request in the waiting queue; The lock request processing module is used to lock the resources corresponding to the head lock request according to the optimistic locking mechanism and remove the head lock request from the waiting queue if the lock request of the client in the waiting queue is the head lock request.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the file locking method based on adaptive optimistic locking according to any one of claims 1 to 3 is implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the file locking method based on adaptive optimistic locking as described in any one of claims 1 to 3 is implemented.

Images