CN112579307A - Physical lock resource allocation detection method and device and electronic equipment - Google Patents

Physical lock resource allocation detection method and device and electronic equipment Download PDF

Info

Publication number
CN112579307A
CN112579307A CN202011454282.4A CN202011454282A CN112579307A CN 112579307 A CN112579307 A CN 112579307A CN 202011454282 A CN202011454282 A CN 202011454282A CN 112579307 A CN112579307 A CN 112579307A
Authority
CN
China
Prior art keywords
physical lock
data processing
processing thread
physical
thread
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011454282.4A
Other languages
Chinese (zh)
Inventor
周信静
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Tencent Cloud Computing Beijing Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202011454282.4A priority Critical patent/CN112579307A/en
Publication of CN112579307A publication Critical patent/CN112579307A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application provides a physical lock resource allocation detection method and device and electronic equipment, and relates to the technical field of cloud. In the implementation of the application, a request for reading and writing data from a database triggered by a target object is responded, and a physical lock request is initiated through a target data processing thread; the physical lock request at least carries identification information of data to be processed; within a preset time length after the physical lock request is initiated, if the physical lock associated with the identification information is not acquired, acquiring current physical lock resource allocation state information; and detecting the physical lock resource allocation state information, and determining the physical lock with the allocation error and the associated data processing thread. The embodiment of the application provides an effective detection scheme for physical lock resource allocation in a database, which can be used for detecting physical lock resource allocation state information, so that after physical locks with allocation errors and associated data processing threads are determined, the physical locks can be corrected in time, and the accuracy of physical lock resource allocation in the database is improved.

Description

Physical lock resource allocation detection method and device and electronic equipment
Technical Field
The present application relates to the field of cloud technologies, and in particular, to a method and an apparatus for detecting allocation of physical lock resources, and an electronic device.
Background
With the steady advance of the current information-based construction process, the database technology is widely applied. The database is a warehouse for storing data, the data is stored according to a specific format, a user can read and write the data stored in the database through a data processing thread in the database, and the data processing thread needs to request a physical lock corresponding to the data when reading and writing the data from the database, so that the data is protected, other users are prevented from modifying or deleting the data, and the integrity of the data is ensured.
At present, in an actual situation, a plurality of data processing threads often concurrently request to read and write data from a database, so that the plurality of data processing threads may allocate different physical locks, and at this time, the physical lock resource allocation may have a problem of an allocation error.
Disclosure of Invention
The embodiment of the application provides a method and a device for detecting allocation of physical lock resources and electronic equipment, and discloses a scheme for effectively detecting the allocation state of the physical lock resources of a database, so that the allocation accuracy of the physical lock resources in the database is improved.
In a first aspect, an embodiment of the present application provides a method for detecting allocation of physical lock resources, including:
responding to a request for reading and writing data from a database triggered by a target object, and initiating a physical lock request through a target data processing thread; the physical lock request at least carries identification information of data to be processed;
within a preset time length after the physical lock request is initiated, if the physical lock associated with the identification information is not acquired, acquiring current physical lock resource allocation state information;
and detecting the physical lock resource allocation state information, and determining the physical lock with the allocation error and the associated data processing thread.
In a second aspect, an embodiment of the present application provides an apparatus for detecting allocation of a physical lock resource, including:
the request unit is used for responding to a request for reading and writing data from a database triggered by a target object and initiating a physical lock request through a target data processing thread; the physical lock request at least carries identification information of data to be processed;
an obtaining unit, configured to obtain current physical lock resource allocation state information if a physical lock associated with the identification information is not obtained within a preset time length after a physical lock request is initiated;
and the detection unit is used for detecting the physical lock resource allocation state information and determining the physical lock with the allocation error and the associated data processing thread.
In a third aspect, an embodiment of the present application provides an electronic device, including:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the physical lock resource allocation detection methods provided herein.
In a fourth aspect, an embodiment of the present application provides a computer-readable medium storing computer-executable instructions for performing the method for detecting allocation of physical lock resources provided in the present application.
The application has the beneficial effects that:
the method comprises the steps that a request for reading and writing data from a database triggered by a target object is responded, and a physical lock request is initiated through a target data processing thread; the physical lock request at least carries identification information of data to be processed; within a preset time length after the physical lock request is initiated, if the physical lock associated with the identification information is not obtained, detecting the current physical lock resource allocation state information, and determining the physical lock with the allocation error and the associated data processing thread; according to the method and the device, the waiting time is detected after the target data processing thread initiates the physical lock request, the waiting time of the target data processing thread is longer than the preset time, the physical lock requested by the target data processing thread is possibly occupied, the current physical lock resource allocation state needs to be detected, and the physical lock resource allocation state information is updated in real time, and within the preset time after the target data processing thread initiates the physical lock request, if the physical lock associated with the identification information is not acquired, the current physical lock resource allocation state information is acquired, the acquired physical lock resource allocation state information is detected, and whether the physical lock with the wrong allocation and the associated data processing thread exist is judged. Therefore, the embodiment of the present application provides an effective detection scheme for physical lock resource allocation in a database, which can be used to detect physical lock resource allocation state information, so that after determining that there are physical locks with allocation errors and associated data processing threads, the physical locks can be corrected in time, and accuracy of physical lock resource allocation in the database is improved.
Drawings
FIG. 1 is a schematic diagram of an exemplary application scenario that may be selected according to an embodiment of the present disclosure;
FIG. 2 is a flowchart illustrating a method for detecting allocation of physical lock resources according to an embodiment of the present disclosure;
FIG. 3 is a diagram illustrating a physical lock resource allocation provided in an embodiment of the present application;
fig. 4 is a schematic diagram of a first corresponding relationship set and a second corresponding relationship set provided in the embodiment of the present application;
FIG. 5 is a schematic diagram of a container array provided in an embodiment of the present application;
FIG. 6 is a diagram illustrating an example of a deadlock loop according to an embodiment of the present application;
FIG. 7 is a diagram illustrating an example of a non-deadlock loop according to an embodiment of the present application;
FIG. 8 is an exemplary diagram of deadlock loops detected from a physical lock resource allocation map as provided by an embodiment of the present application;
FIG. 9 is a schematic diagram of a first deadlock loop according to an embodiment of the present application;
FIG. 10 is a schematic diagram of a second deadlock loop according to an embodiment of the present application;
FIG. 11 is a schematic diagram of a third deadlock loop according to an embodiment of the present application;
FIG. 12 is a schematic structural diagram of an apparatus for detecting allocation of physical lock resources according to an embodiment of the present application;
fig. 13 is a schematic structural diagram of an electronic device in an embodiment of the present application;
fig. 14 is a schematic structural diagram of a computing device in an embodiment of the present application.
Detailed Description
In order to make the technical solutions disclosed in the present application better understood, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
Some terms appearing herein are explained below:
1. MySQL database: MySQL is an open source code Relational Database Management System (RDBMS) that uses the most common Database Management Language, Structured Query Language (SQL), to perform Database Management. MySQL is open source code so anyone can download it under the permission of General Public License (GPL) and modify it according to personalized needs. MySQL is of great interest because of its speed, reliability and adaptability. Most people believe MySQL is the best choice to manage content without requiring transactional processing.
2. Service (Server) layer of MySQL: the MySQL database is responsible for processing components with functions such as SQL syntax parsing, SQL statement optimization, SQL statement execution, MySQL protocol, etc., and interfaces with a plurality of storage engines for managing data.
3. Storage engine layer of MySQL: and the data storage and extraction in MySQL are carried out. Similar to the file system under Linux, each storage engine has its advantages and disadvantages. The intermediate service layer communicates with the storage engines through APIs, and these API interfaces mask differences between different storage engines, making these differences transparent to the query process of the upper layer. The storage engine API contains tens of underlying functions for performing operations such as "start a transaction" or "fetch a line of records from a primary key. But the storage engine does not parse SQL (except the InnoDB, which parses foreign key definitions because the MySQL server itself does not implement this functionality), the different storage engines do not communicate with each other, but simply respond to the requests of the upper level server.
4. Physical lock: the execution of the concurrent thread on the key code area and the modification of the data structure are protected from causing inconsistency, and the execution and the modification of the key code area are generally realized by adopting a lock primitive provided by an operating system, such as Linux _ mutex _ t related API.
5. Physical lock resource allocation map: directed graph, there are two types of nodes: < thread >, < physical lock >, represent the thread and physical lock resources present in the system, respectively. There are two types of edges: [ request ], [ occupied ]. Where the starting point of the [ request ] edge is a < thread > node and the end point is a < physical lock >, indicating that a thread is requesting a physical lock; the start point of the [ occupied ] edge is the < physical lock > node and the end point is the < thread > node, indicating that some physical lock resource is occupied by some thread.
6. Physical lock deadlock loop: in the database system, a physical lock resource allocation diagram comprises a plurality of data processing threads and physical locks, if a loop which is connected end to end in the physical lock resource allocation diagram is detected, the loop is called a physical lock deadlock loop, and the physical locks and the data processing threads contained in the physical lock deadlock loop are the physical locks and the data processing threads which are wrongly allocated.
7. A terminal: also known as User Equipment (UE), Mobile Station (MS), Mobile Terminal (MT), etc., is a device that provides voice and/or data connectivity to a User, for example, a handheld device with a wireless connection function, a vehicle-mounted device, etc. Currently, some examples of terminals are: mobile phone (Mobile phone), tablet computer, notebook computer, palm computer, Mobile Internet Device (MID).
8. A client: the APP may be software APP (Application), or may be terminal equipment. The system is provided with a visual display interface and can interact with a user; is corresponding to the server, and provides local service for the client. For software applications, except some applications that are only run locally, the software applications are generally installed on a common client terminal and need to be run in cooperation with a server terminal. After the internet has developed, more common applications include e-mail clients for e-mail receiving and sending, and instant messaging clients. For such applications, a corresponding server and a corresponding service program are required in the network to provide corresponding services, such as database services, configuration parameter services, and the like, so that a specific communication connection needs to be established between the client terminal and the server terminal to ensure the normal operation of the application program.
The following briefly introduces the design concept of the embodiments of the present application:
cloud technology refers to a hosting technology for unifying serial resources such as hardware, software, network and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data.
Cloud technology (Cloud technology) is based on a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied in a Cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing.
Database (Database), which can be regarded as an electronic file cabinet in short, a place for storing electronic files, a user can add, query, update, delete, etc. to data in files. A "database" is a collection of data that is stored together in a manner that can be shared by multiple users, has as little redundancy as possible, and is independent of the application.
A Database Management System (DBMS) is a computer software System designed for managing a Database, and generally has basic functions such as storage, interception, security assurance, and backup. The database management system may be categorized according to the database model it supports, such as relational, Extensible Markup Language (XML); or classified according to the type of computer supported, e.g., server cluster, mobile phone; or classified according to the Query Language used, such as Structured Query Language (SQL), XQuery; or by performance impulse emphasis, e.g., maximum size, maximum operating speed; or other classification schemes. Regardless of the manner of classification used, some DBMSs are capable of supporting multiple query languages across categories, for example, simultaneously.
At present, a user can read and write data stored in a database through a data processing thread, generally, in an actual situation, a plurality of data processing threads often concurrently request to read and write data from the database, and at this time, different physical locks need to be allocated to the plurality of data processing threads, so that a problem of a physical lock resource allocation error may be encountered.
The method comprises the steps that a request for reading and writing data from a database triggered by a target object is responded, and a physical lock request is initiated through a target data processing thread; the physical lock request at least carries identification information of data to be processed; within a preset time length after the physical lock request is initiated, if the physical lock associated with the identification information is not obtained, detecting the current physical lock resource allocation state information, and determining the physical lock with the allocation error and the associated data processing thread; according to the method and the device, the waiting time is detected after the target data processing thread initiates the physical lock request, the waiting time of the target data processing thread is longer than the preset time, the physical lock requested by the target data processing thread is possibly occupied, the current physical lock resource allocation state needs to be detected, and the physical lock resource allocation state information is updated in real time, and within the preset time after the target data processing thread initiates the physical lock request, if the physical lock associated with the identification information is not acquired, the current physical lock resource allocation state information is acquired, the acquired physical lock resource allocation state information is detected, and whether the physical lock with the wrong allocation and the associated data processing thread exist is judged. Therefore, the embodiment of the present application provides an effective detection scheme for physical lock resource allocation in a database, which can be used to detect physical lock resource allocation state information, so that after determining that there are physical locks with allocation errors and associated data processing threads, the physical locks can be corrected in time, and accuracy of physical lock resource allocation in the database is improved.
After introducing the design concept of the embodiment of the present application, some simple descriptions are provided below for application scenarios to which the technical solution of the embodiment of the present application can be applied, and it should be noted that the application scenarios described below are only used for describing the embodiment of the present application and are not limited. In a specific implementation process, the technical scheme provided by the embodiment of the application can be flexibly applied according to actual needs.
Fig. 1 is a schematic diagram of an exemplary optional application scenario according to an embodiment of the present application, and includes a target object 10, a terminal device 11, and a remote server 12; the target object 10 can operate a client installed on the terminal device 11 to access a database located in the remote server 12, and read and write data from the database in the remote server 12.
The target object 10 operates the client installed on the terminal device 11, and in the running process of the client, according to the operation of the target object 10 in the client, if the client needs to read and write data from the database of the remote server 12, the client sends a request for reading and writing data to the database of the remote server 12; the remote server 12 allocates a target data processing thread for the read-write data request initiated by the client, and the target data processing thread initiates a physical lock request; the physical lock request at least carries identification information of data to be processed; if the remote server 12 determines that the target data processing thread does not acquire the physical lock associated with the identification information within the preset time after the target data processing thread initiates the physical lock request, the current physical lock resource allocation state information is acquired, and the remote server 12 detects the physical lock resource allocation state information to determine the physical lock with the allocation error and the associated data processing thread.
It should be noted that the database may be a database in a server corresponding to a client running in the terminal device 11.
In the following, in conjunction with the application scenarios described above, a method for detecting allocation of physical lock resources provided in an exemplary embodiment of the present application is described with reference to fig. 2 to fig. 6. It should be noted that the above application scenarios are only presented to facilitate understanding of the spirit and principles of the present application, and the embodiments of the present application are not limited in this respect. Rather, embodiments of the present application may be applied to any scenario where applicable.
As shown in fig. 2, which is a schematic flowchart of a method for detecting allocation of a physical lock resource according to an embodiment of the present application, the method may include the following steps:
step S201, responding to a request for reading and writing data from a database triggered by a target object, and initiating a physical lock request through a target data processing thread; the physical lock request at least carries identification information of data to be processed;
step S202, within a preset duration after the physical lock request is initiated, if the physical lock associated with the identification information is not acquired, acquiring current physical lock resource allocation state information;
step S203, detecting the physical lock resource allocation state information, and determining the physical lock with the allocation error and the associated data processing thread.
When the target object triggers a request for reading and writing data from the database in the embodiment of the application, an optional application scenario is that, for example, the target object may be a company manager, the target object accesses a company server through a client running on a terminal device, and reads company employee salary data a from the database of the company server; the target object triggers a request for reading and writing data from the database, the company server distributes a target data processing thread T to perform data reading and writing operation, the target data processing thread T initiates a physical lock request, and requests a physical lock L to lock the data A, so that the data A is protected, other objects are prevented from being modified or deleted, and the integrity of the data A is ensured.
After a physical lock request is initiated through a target data processing thread, an optional implementation manner is that, in the embodiment of the present application, a physical lock locking wait timeout detection technology may be used to determine whether a wait duration of the target data processing thread after initiating the request physical lock exceeds a preset duration; for example, the target data processing thread T initiates a request for requesting the physical lock L, and at this time, the target data processing thread T is monitored by using a physical lock locking wait timeout detection technique, and if it is monitored that the target data processing thread T does not acquire the physical lock L within a preset time (assuming that the preset time is 10s) after initiating the request for the physical lock L, it is determined that the waiting time of the target data processing thread T after initiating the request for the physical lock L exceeds the preset time.
An optional implementation manner is that, in the embodiment of the present application, the physical lock resource allocation status information may be generated according to the following manner:
acquiring each data processing thread executing data read-write operation in a database; and generating physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread.
It should be noted that the physical locks requested by the data processing threads executing the data read/write operation and the occupied physical locks in the database system are updated in real time, and the physical lock resource allocation status information is dynamically generated in real time according to the physical locks requested by the data processing threads executing the read/write operation or the occupied physical locks in the database system.
In some embodiments, the physical lock resource allocation status information may be a physical lock resource allocation map.
In an optional implementation manner, in the embodiment of the present application, the physical lock resource allocation map may be generated according to the following manner:
taking each data processing thread, a physical lock requested by each data processing thread and a physical lock occupied by each data processing thread as nodes, taking connecting lines between the data processing threads and the requested physical locks in the plurality of nodes as edges, and taking connecting lines between the data processing threads and the occupied physical locks in the plurality of nodes as edges;
the direction of the edge between the data processing thread and the requested physical lock is different from the direction of the edge occupied by the data processing thread;
an optional implementation manner is that, in the embodiment of the present application, a direction from the data processing thread to the requested physical lock may be taken as a direction for connecting an edge between the data processing thread and the requested physical lock, and a direction from the physical lock occupied by the data processing thread to the data processing thread may be taken as a direction for connecting an edge between the data processing thread and the occupied physical lock.
In implementation, the edge between the data processing thread and the physical lock requested is represented in the physical lock resource allocation diagram in the form of an edge < thread T > - [ request ] - > < physical lock L >, and the edge between the physical locks occupied by the data processing thread is represented in the physical lock resource allocation diagram in the form of an edge < physical lock L > - < occupied > - > < thread T >.
It should be noted that, in the database, the physical lock resource allocation map is a directed map, and the physical lock resource allocation map is dynamically generated in real time according to the physical lock requested or occupied by each data processing thread executing read-write operation in the database; and the data processing threads for processing different layers of data in the whole database and the allocation situation of the physical lock resources requested or occupied can be integrated in the same physical lock resource allocation diagram.
For example, as shown in fig. 3, which is a schematic diagram of a physical lock resource allocation provided by an embodiment of the present application, a data processing thread of a database service layer is processed by a thread T1Thread T2Thread T3For example, the data processing thread of the database engine layer is processed with thread T4Thread T5Thread T6For example, thread T1Requesting a physical lock L1Thread T2Occupying physical lock L1Thread T2Requesting a physical lock L3Thread T3Occupying physical lock L3Thread T3Requesting a physical lock L4Thread T2Occupying physical lock L4Thread T4Requesting a physical lock L7Thread T6Occupying physical lock L7Thread T6Requesting a physical lock L6Thread T5Occupying physical lock L6Thread T5Requesting a physical lock L2Thread T3Occupying physical lock L2(ii) a The data processing thread requests and occupied physical locks for processing the data of the database service layer and the data of the engine layer are integrated into the same physical lock resource allocation diagram in the following edge forms:<thread T1>- [ request]-><Physical lock L1>、<Physical lock L1>- [ occupied]-><Thread T2>、<Thread T2>- [ request]-><Physical lock L3>、<Physical lock L3>- [ occupied]-><Thread T3>、<Thread T3>- [ request]-><Physical lock L4>、<Physical lock L4>- [ occupied]-><Thread T2>、<Thread T4>- [ request]-><Physical lock L7>、<Physical lock L7>- [ occupied]-><Thread T6>、<Thread T6>- [ request]-><Physical lock L6>、<Physical lock L6>- [ occupied]-><Thread T5>、<Thread T5>- [ request]-><Physical lock L2>、<Physical lock L2>- [ quiltOccupancy]-><Thread T3>。
Before generating the physical lock resource allocation state information, the embodiment of the application needs to acquire the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread; in the embodiment of the present application, the manners of acquiring the data processing thread request and the physical lock occupied by the data processing thread are different for the data processing threads at different layers of the database, and the manners of acquiring the data processing thread request and the physical lock occupied by the data processing thread are respectively described below for different types of data processing threads.
1. The data processing thread is a first data processing thread for processing read-write data requests in the database engine layer;
acquiring the physical lock requested by each first data processing thread from the first corresponding relation set;
the first corresponding relation set stores a first corresponding relation between a first data processing thread initiating a physical lock request and a requested physical lock, and the first corresponding relation is generated after the first data processing thread initiates the physical lock request and stored in the first corresponding relation set.
It should be noted that, in the database, when one data processing thread reads and writes data, and cannot acquire the physical lock corresponding to the data immediately, the data processing thread may generate a physical lock request for acquiring the physical lock.
Acquiring physical locks occupied by each first data processing thread from the second corresponding relation set;
and the second corresponding relation is generated after the physical lock requested by the first data processing thread in the first corresponding relation set is successfully occupied and is stored in the second corresponding relation set.
It should be noted that after the physical lock requested by the first data processing thread in the first corresponding relationship set is successfully occupied and before the physical lock is stored in the second corresponding relationship set, the first corresponding relationship between the first data processing thread initiating the physical lock request and the requested physical lock, which is stored in the first corresponding relationship set, needs to be deleted.
When the physical lock resource allocation state information is a physical lock resource allocation diagram, the corresponding relation between the data processing threads in the first corresponding relation set and the requested physical locks and the corresponding relation between the data processing threads in the second corresponding relation set and the occupied physical locks can be stored in a side form, so that the physical lock resource allocation diagram is generated according to the first corresponding relation set and the second corresponding relation set when the physical lock resource allocation diagram is generated; the correspondence between the data processing thread in the first correspondence set and the requested physical lock may be expressed as < thread T > - [ request ] - > < physical lock L >, and the correspondence between the data processing thread in the second correspondence set and the occupied physical lock may be expressed as < physical lock L > - < occupied > - > < thread T >.
For example, a data processing thread that processes data in the database engine layer is threaded with thread T1Thread T2Thread T3For example, thread T1Requesting a physical lock L1Thread T2Successfully seizing physical lock L1And L2Thread T2Requesting a physical lock L3Thread T3Successfully seizing physical lock L3Thread T3Requesting a physical lock L4If so, the first corresponding relationship set and the second corresponding relationship set are as shown in fig. 4; wherein, the first corresponding relation is set with<Thread T>- [ request]-><Physical lock L>Formally representing the first corresponding relation in the second corresponding relation set<Physical lock L>-<Is occupied>-><Thread T>Formally representing the second correspondence;
thread T1Requesting a physical lock L1At this point, the requesting physical lock L is initiated1Thread T of1With the requested physical lock L1Generating a first corresponding relation and<thread T1>- [ request]-><Physical lock L1>Is stored in the first set of correspondences;
thread T2Successfully seizing physical lock L1And L2And thread T2Requesting a physical lock L3At this point, the requesting physical lock L is initiated3Thread T of2With the requested physical lock L3A first correspondence relationship is generated to<Thread T2>- [ request]-><Physical lock L3>Is stored in a first set of correspondences, thread T2With occupied physical lock L1Generate a second corresponding relation between them and<physical lock L1>-<Is occupied>-><Thread T2>The form is stored in a second corresponding relation set, thread T2With occupied physical lock L2Generate a second corresponding relation between them and<physical lock L2>-<Is occupied>-><Thread T2>The form is stored in a second corresponding relation set;
thread T3Successfully seizing physical lock L3And thread T3Requesting a physical lock L4At this point, the requesting physical lock L is initiated4Thread T of3With the requested physical lock L4A first corresponding relation generated between the first and second<Thread T3>- [ request]-><Physical lock L4>Is stored in a first set of correspondences, thread T3With occupied physical lock L3Generate a second corresponding relation between them and<physical lock L3>-<Is occupied>-><Thread T3>The form is stored in a second set of correspondences.
2. The data processing thread is a second data processing thread for processing read-write data requests in the database service layer;
traversing the container array corresponding to each second data processing thread;
determining the physical lock requested by each second data processing thread and the physical lock occupied by each second data processing thread according to the binary information stored in the container array corresponding to each second data processing thread; the binary information stored in the container array comprises at least one of a physical lock of the second data processing thread and the request, and a physical lock of the second data processing thread and the occupation.
An optional implementation manner is that the binary information stored in the container array corresponding to each second data processing thread may be represented as < ID (L), Status >, where ID (L) may be represented as an ID of a physical lock L requested by the second data processing thread, Status represents a lock request state, and a value is Requesting or occupied;
it should be noted that, for each second data processing thread, the locking request Requesting physical lock L is stored in the container array in the form of < L, Requesting >; when the physical lock L is successfully occupied, < L, Requesting > stored in the container array at this time is replaced with < L, Owned >.
For example, a data processing thread that processes data in the database service layer is threaded with thread T1Thread T2Thread T3For example, thread T1Requesting a physical lock L1Thread T2Successfully seizing physical lock L1And L2Thread T2Requesting a physical lock L3Thread T3Successfully seizing physical lock L3Thread T3Requesting a physical lock L4Then, a schematic diagram of a container array provided in the embodiment of the present application is shown in fig. 5;
in the database service layer, there is a corresponding container array C for each thread, e.g., thread T1The corresponding container array is C1Thread T2The corresponding container array is C2Thread T3The corresponding container array is C3Thread T4The corresponding container array is C4
Thread T1Requesting a physical lock L1At this time, thread T1Corresponding container array C1The binary information stored in<L1,Requesting>;
Thread T2Successfully seizing physical lock L1And L2And thread T2Requesting a physical lock L3At this time, thread T2Corresponding container array C2The binary information stored in<L1,Owned>、<L2,Owned>And<L3,Requesting>;
thread T3Successfully seizing physical lock L3And thread T3Requesting a physical lock L4At this time, thread T3Corresponding container array C3The binary information stored in<L3,Owned>And<L4,Requesting>。
it should be noted that each data processing thread for processing data in the engine layer and the service layer in the database may occupy multiple physical locks, and when a certain data processing thread occupies a certain physical lock, it may request other physical locks;
the physical lock requested by the data processing thread is determined by the data read and written by the data processing thread.
In the embodiment of the application, within a preset time length after a data processing thread initiates a physical lock request, if the physical lock is not acquired, detecting physical lock resource allocation state information is triggered to determine that a physical lock with an allocation error and a related data processing thread exist, wherein the physical lock resource allocation state information in the following embodiments takes a physical lock resource allocation diagram as an example;
in an optional implementation manner, in the embodiment of the present application, the physical lock resource allocation map may be detected according to the following manner;
and if a node loop which sequentially connects the nodes according to the direction of the edge is detected from the physical lock resource allocation diagram according to the directions of the nodes and the edges connected between the nodes in the physical lock resource allocation diagram, determining the physical lock and the data processing thread contained in the node loop as a physical lock with an allocation error and an associated data processing thread.
When there is an allocation error in a physical lock and a data processing thread in a database, it is more common that when a node loop in which nodes are sequentially connected in an edge direction is detected from a physical lock allocation diagram as a deadlock loop, there is an allocation error in the physical lock and the data processing thread in the deadlock loop.
In the following embodiments, node loops with physical locks and data processing thread allocation errors are deadlock loops as an example;
it should be noted that the deadlock loop detected from the physical lock resource allocation map may be one or more, and each deadlock loop may include multiple data processing threads and physical locks.
If an end-to-end loop exists in the physical lock resource allocation diagram and the end are the same data processing thread, then the deadlock is considered to occur, and the detected loop is the deadlock loop.
For example, as shown in fig. 6, an exemplary diagram of a deadlock loop provided by an embodiment of the present application is shown, the deadlock loop has a loop and includes a starting point, and the deadlock loop sequentially includes<Thread T1>- [ request]-><Physical lock L1>,<Physical lock L1>- [ occupied]-><Thread T2>,<Thread T2>- [ request]-><Physical lock L3>,<Physical lock L3>- [ occupied]-><Thread T3>,<Thread T3>- [ request]-><Physical lock L4>,<Physical lock L4>- [ occupied]-><Thread T1>These edges, and it can be seen from FIG. 6 that the starting and ending nodes of the deadlock loop are both threads T1
For another example, as shown in fig. 7, an exemplary graph of non-deadlock loops is provided for an embodiment of the present application, and the exemplary graph includes no loops and sequentially includes<Thread T1>- [ request]-><Physical lock L1>,<Physical lock L1>- [ occupied]-><Thread T2>,<Thread T2>- [ request]-><Physical lock L3>,<Physical lock L3>- [ occupied]-><Thread T3>These edges;
FIG. 8 is a diagram illustrating an example of deadlock loops detected from a physical lock resource allocation map according to an embodiment of the present application, where the generated physical lock resource allocation map includes the following edges:<thread T1>- [ request]-><Physical lock L1>、<Physical lock L1>- [ occupied]-><Thread T2>、<Thread T2>- [ request]-><Physical lock L3>、<Physical lock L3>- [ occupied]-><Thread T3>、<Thread T3>- [ request]-><Physical lock L2>、<Physical lock L2>- [ occupied]-><Thread T6>、<Thread T6>- [ request]-><Physical lock L4>、<Physical lock L4>- [ occupied]-><Thread T4>、<Thread T4>- [ request]-><Physical lock L6>、<Physical lock L6>- [ occupied]-><Thread T5>、<Thread T5>- [ request]-><Physical lock L5>、<Physical lock L5>- [ occupied]-><Thread T6>(ii) a As can be seen in FIG. 8, a deadlock loop is detected from the physical lock resource allocation map:<thread T6>- [ request]-><Physical lock L4>-<Physical lock L4>- [ occupied]-><Thread T4>-<Thread T4>- [ request]-><Physical lock L6>-<Physical lock L6>- [ occupied]-><Thread T5>-<Thread T5>- [ request]-><Physical lock L5>-<Physical lock L5>- [ occupied]-><Thread T6>And the starting node and the ending node of the deadlock loop are threads T6
In a specific implementation, there may be multiple situations of physical locks in deadlock loops detected from the physical lock resource allocation map, for example, the physical locks are all physical locks for processing database engine layer data, the physical locks for processing the physical locks are all physical locks for processing database service layer data, and the physical locks include physical locks for processing database engine layer data and physical locks for processing database service layer data;
the following describes the above 3 cases.
1. The physical locks in the deadlock loop are all physical locks that handle the database engine layer data.
Fig. 9 is a schematic diagram of a deadlock loop according to an embodiment of the present application, in which a data processing line for processing database engine layer data is providedThread T1Thread T2Thread T3For example, thread T1Requesting a physical lock L3Thread T2Occupying physical lock L3Thread T2Requesting a physical lock L1Thread T3Occupying physical lock L1Thread T3Requesting a physical lock L2Thread T1Occupying physical lock L2
Thread T1Responding to a request of reading and writing data A from the database triggered by a target object, wherein the physical lock corresponding to the data A is L3Then thread T1Generating a requesting physical lock L3When thread T is monitored, a lock request is made1The physical lock L is not acquired within a preset duration after the physical lock request is initiated3Then obtaining the current physical lock resource allocation diagram, starting deadlock detection and using thread T1As a starting point, along<Thread T1>- [ request]-><Physical lock L3>Starting to detect the currently acquired physical lock resource allocation diagram, and finding the physical lock L in the detection process3By thread T2Occupied, and thread T is now2Requesting to acquire physical lock L1At this time, the physical lock L1By thread T3Occupation, thread T3Requesting to acquire physical lock L2And physical lock L2By thread T1If it is occupied, a deadlock loop is formed.
2. The physical locks in the deadlock loop are all physical locks that handle the database service layer data.
FIG. 10 is a diagram illustrating a deadlock loop according to a second embodiment of the present application, in which a thread T is used to process a data processing thread of database service layer data4Thread T5Thread T6For example, thread T4Requesting a physical lock L4Thread T5Occupying physical lock L4Thread T5Requesting a physical lock L6Thread T6Occupying physical lock L6Thread T6Requesting a physical lock L5Thread T4Occupying physical lock L5
Thread T4Responding to a request of reading and writing data B from the database triggered by the target object, wherein the physical lock corresponding to the data B is L4Then thread T4Generating a requesting physical lock L4When thread T is monitored, a lock request is made4The physical lock L is not acquired within a preset duration of initiating the physical lock request4Then obtaining the current physical lock resource allocation diagram, starting deadlock detection and using thread T4As a starting point, along<Thread T4>- [ request]-><Physical lock L4>Starting to detect the currently acquired physical lock resource allocation diagram, and finding the physical lock L in the detection process4By thread T5Occupied, and thread T is now5Requesting to acquire physical lock L6At this time, the physical lock L6By thread T6Occupation, thread T6Requesting to acquire physical lock L5And physical lock L5By thread T4If it is occupied, a deadlock loop is formed.
3. The physical locks in the deadlock loop are physical locks that handle database engine layer data and physical locks that handle database service layer data.
FIG. 11 is a schematic diagram of a third deadlock loop provided in an embodiment of the present application, in which a data processing thread for processing database engine layer data is a thread T7Thread T9Thread T11For example, a data processing thread that processes database service layer data is thread T8Thread T10For example, thread T9Requesting a physical lock L7Thread T7Occupying physical lock L7Thread T7Requesting a physical lock L9Thread T8Occupying physical lock L9Thread T10Requesting a physical lock L11Thread T9Occupying physical lock L11
Thread T9Responding to a request of reading and writing data C from the database triggered by a target object, wherein the physical lock corresponding to the data C is L7Then thread T9Generating a requesting physical lock L7When thread T is monitored, a lock request is made10Upon initiation of a physical lock requestPhysical lock L is not acquired within preset duration7Then obtaining the current physical lock resource allocation diagram, starting deadlock detection and using thread T9As a starting point, along<Thread T9>- [ request]-><Physical lock L7>Starting to detect the currently acquired physical lock resource allocation diagram, and finding the physical lock L in the detection process7By thread T7Occupied, and thread T is now7Requesting to acquire physical lock L9At this time, the physical lock L9By thread T8Occupation, thread T8Requesting to acquire physical lock L10And physical lock L10By thread T10Occupation, thread T10Requesting a physical lock L11And physical lock L11By thread T9If it is occupied, a deadlock loop is formed.
As shown in fig. 12, a schematic structural diagram of an apparatus 1200 for detecting allocation of a physical lock resource in an embodiment of the present application includes:
a request unit 1200, configured to respond to a request for reading and writing data from a database triggered by a target object, and initiate a physical lock request through a target data processing thread; the physical lock request at least carries identification information of data to be processed;
an obtaining unit 1201, configured to obtain, within a preset duration after the physical lock request is initiated, current physical lock resource allocation state information if the physical lock associated with the identification information is not obtained;
the detecting unit 1202 is configured to detect the physical lock resource allocation status information, and determine that there are a physical lock with an allocation error and an associated data processing thread.
Optionally, the obtaining unit 1201 is further configured to:
acquiring each data processing thread executing data read-write operation in a database;
and generating physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread.
Optionally, the obtaining unit 1201 is specifically configured to:
taking each data processing thread, a physical lock requested by each data processing thread and a physical lock occupied by each data processing thread as nodes;
connecting lines between the data processing threads in the plurality of nodes and the requested physical locks as edges, and connecting lines between the data processing threads in the plurality of nodes and the occupied physical locks as edges; wherein, the direction of the edge between the data processing thread and the requested physical lock is different from the direction of the edge between the data processing thread and the occupied physical lock;
and generating a physical lock resource allocation graph according to the determined nodes and edges.
Optionally, the obtaining unit 1201 is specifically configured to:
acquiring the physical lock requested by each first data processing thread from the first corresponding relation set; the first corresponding relation set stores a first corresponding relation between a first data processing thread initiating a physical lock request and a requested physical lock, and the first corresponding relation is generated after the first data processing thread initiates the physical lock request and stored in the first corresponding relation set;
acquiring physical locks occupied by each first data processing thread from the second corresponding relation set; and the second corresponding relation is generated after the physical lock requested by the first data processing thread in the first corresponding relation set is successfully occupied and is stored in the second corresponding relation set.
Optionally, the obtaining unit 1201 is specifically configured to:
traversing the container array corresponding to each second data processing thread;
determining the physical lock requested by each second data processing thread and the physical lock occupied by each second data processing thread according to the binary information stored in the container array corresponding to each second data processing thread; the binary information stored in the container array comprises at least one of a physical lock of the second data processing thread and the request, and a physical lock of the second data processing thread and the occupation.
Optionally, the obtaining unit 1201 is specifically configured to:
detecting the physical lock resource allocation map;
if a node loop for sequentially connecting the nodes according to the direction of the edge is detected from the physical lock resource allocation diagram according to the direction of each node and the direction of the edge connected between the nodes in the physical lock resource allocation diagram; the physical lock and data processing thread included in the node loop are determined to be the physical lock and associated data processing thread for which there is an allocation error.
For convenience of description, the above parts are separately described as modules (or units) according to functional division. Of course, the functionality of the various modules (or units) may be implemented in the same one or more pieces of software or hardware when implementing the present application.
As will be appreciated by one skilled in the art, each aspect of the present application may be embodied as a system, method or program product. Accordingly, each aspect of the present application may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.
In some possible implementations, embodiments of the present application further provide an electronic device, and referring to fig. 13, an electronic device 1300 may include at least one processor 1301 and at least one memory 1302. The memory 1302 stores therein program code, which, when executed by the processor 1301, causes the processor 1301 to perform the steps of the method for detecting allocation of physical lock resources according to various exemplary embodiments of the present application described above in the present specification, for example, the processor 1301 may perform the steps as shown in fig. 2.
In some possible implementations, the present application further provides a computing device, which may include at least one processing unit and at least one storage unit. Wherein the storage unit stores program code, which, when executed by the processing unit, causes the processing unit to perform the steps of the method for detecting allocation of physical lock resources according to various exemplary embodiments of the present application described above in this specification, for example, the processor 1301 may perform the steps as shown in fig. 2.
A computing device 1400 according to such an embodiment of the present application is described below with reference to fig. 14. The computing device 1400 of fig. 14 is only one example and should not be taken as limiting the scope of use and functionality of embodiments of the present application.
As with fig. 14, computing device 1400 is embodied in the form of a general purpose computing device. Components of computing device 1400 may include, but are not limited to: the at least one processing unit 1401, the at least one memory unit 1402, and a bus 1403 connecting the different system components (including the memory unit 1402 and the processing unit 1401).
Bus 1403 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.
The storage unit 1402 may include a readable medium in the form of volatile memory, such as Random Access Memory (RAM)1421 or cache memory unit 1422, and may further include Read Only Memory (ROM) 1423.
Storage unit 1402 may also include a program/utility 1425 having a set (at least one) of program modules 1324, such program modules 1424 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
The computing device 1400 may also communicate with one or more external devices 1404 (e.g., keyboard, pointing device, etc.), with one or more devices that enable a user to interact with the computing device 1400, or with any devices (e.g., router, modem, etc.) that enable the computing device 1400 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 1405. Also, computing device 1400 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), or a public network, such as the internet) through network adapter 1406. As shown, the network adapter 1406 communicates with other modules for the computing device 1400 over a bus 1403. It should be understood that although not shown in the figures, other hardware or software modules may be used in conjunction with computing device 1400, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
In some possible embodiments, each aspect of the method for detecting allocation of physical lock resources provided in the present application may also be implemented in the form of a program product including program code for causing a computer device to perform the steps in detecting allocation of physical lock resources according to various exemplary embodiments of the present application described above in this specification when the program product is run on the computer device, for example, the computer device may perform the steps shown in fig. 2.
The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (10)

1. A method for detecting allocation of physical lock resources, comprising:
responding to a request for reading and writing data from a database triggered by a target object, and initiating a physical lock request through a target data processing thread; the physical lock request at least carries identification information of data to be processed;
within a preset time length after the physical lock request is initiated, if the physical lock associated with the identification information is not acquired, acquiring current physical lock resource allocation state information;
and detecting the physical lock resource allocation state information, and determining the physical lock with the allocation error and the associated data processing thread.
2. The method of claim 1, prior to obtaining current physical lock resource allocation status information, further comprising:
acquiring each data processing thread executing data read-write operation in the database;
and generating the physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread.
3. The method of claim 2, wherein the physical lock resource allocation status information is a physical lock resource allocation map;
the generating the physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread specifically includes:
taking each data processing thread, the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread as nodes;
connecting lines between the data processing threads in the plurality of nodes and the requested physical locks as edges, and connecting lines between the data processing threads in the plurality of nodes and the occupied physical locks as edges; wherein, the direction of the edge between the data processing thread and the requested physical lock is different from the direction of the edge between the data processing thread and the occupied physical lock;
and generating a physical lock resource allocation graph according to the determined nodes and edges.
4. The method of claim 2, wherein if the data processing thread is a first data processing thread that processes read and write data requests in a database engine layer;
before generating the physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread, the method further includes:
acquiring the physical lock requested by each first data processing thread from the first corresponding relation set; the first corresponding relation set stores a first corresponding relation between a first data processing thread initiating a physical lock request and a requested physical lock, and the first corresponding relation is generated after the first data processing thread initiates the physical lock request and stored in the first corresponding relation set;
acquiring physical locks occupied by each first data processing thread from the second corresponding relation set; and the second corresponding relationship set stores a second corresponding relationship between the first data processing thread and the occupied physical lock, and the second corresponding relationship is generated after the physical lock requested by the first data processing thread in the first corresponding relationship set is successfully occupied and stored in the second corresponding relationship set.
5. The method of claim 2, wherein if the data processing thread is a second data processing thread that processes read and write data requests in a database service layer;
before generating the physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread, the method further includes:
traversing the container array corresponding to each second data processing thread;
determining the physical lock requested by each second data processing thread and the physical lock occupied by each second data processing thread according to the binary information stored in the container array corresponding to each second data processing thread; the binary information stored in the container array comprises at least one of a physical lock requested by the second data processing thread and a physical lock occupied by the second data processing thread.
6. The method of claim 3, wherein said detecting the physical lock resource allocation status information to determine that there is a physical lock with an allocation error and an associated data processing thread comprises:
detecting the physical lock resource allocation map;
if a node loop for sequentially connecting the nodes according to the direction of the edge is detected from the physical lock resource allocation diagram according to the direction of each node and the direction of the edge connected between the nodes in the physical lock resource allocation diagram; the physical lock and data processing thread included in the node loop are determined to be the physical lock and associated data processing thread for which there is an allocation error.
7. An apparatus for detecting allocation of a physical lock resource, comprising:
the request unit is used for responding to a request for reading and writing data from a database triggered by a target object and initiating a physical lock request through a target data processing thread; the physical lock request at least carries identification information of data to be processed;
an obtaining unit, configured to obtain current physical lock resource allocation state information if a physical lock associated with the identification information is not obtained within a preset time length after a physical lock request is initiated;
and the detection unit is used for detecting the physical lock resource allocation state information and determining the physical lock with the allocation error and the associated data processing thread.
8. The apparatus as claimed in claim 7, wherein said obtaining unit is further configured to, prior to obtaining current physical lock resource allocation status information:
acquiring each data processing thread executing data read-write operation in the database;
and generating the physical lock resource allocation state information according to the physical lock requested by each data processing thread and the physical lock occupied by each data processing thread.
9. An electronic device, comprising a processor and a memory, wherein the memory stores program code which, when executed by the processor, causes the processor to perform the steps of the method of any of claims 1 to 6.
10. A computer-readable storage medium, characterized in that it comprises program code for causing an electronic device to carry out the steps of the method according to any one of claims 1 to 6, when said program code is run on said electronic device.
CN202011454282.4A 2020-12-10 2020-12-10 Physical lock resource allocation detection method and device and electronic equipment Pending CN112579307A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011454282.4A CN112579307A (en) 2020-12-10 2020-12-10 Physical lock resource allocation detection method and device and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011454282.4A CN112579307A (en) 2020-12-10 2020-12-10 Physical lock resource allocation detection method and device and electronic equipment

Publications (1)

Publication Number Publication Date
CN112579307A true CN112579307A (en) 2021-03-30

Family

ID=75131381

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011454282.4A Pending CN112579307A (en) 2020-12-10 2020-12-10 Physical lock resource allocation detection method and device and electronic equipment

Country Status (1)

Country Link
CN (1) CN112579307A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113691434A (en) * 2021-08-31 2021-11-23 深圳云天励飞技术股份有限公司 Data transmission system, method, electronic device, and storage medium
WO2023029591A1 (en) * 2021-09-03 2023-03-09 海光信息技术股份有限公司 Processor, physical register management method, and electronic apparatus
WO2024046089A1 (en) * 2022-08-31 2024-03-07 华为技术有限公司 Lock-holding process detection method and related device

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120131159A1 (en) * 2010-11-18 2012-05-24 International Business Machines Corporation Method and system for reducing message passing for contention detection in distributed sip server environments
US20140040220A1 (en) * 2012-07-31 2014-02-06 Hideaki Kimura Methods and systems for deadlock detection
US20140258255A1 (en) * 2013-03-11 2014-09-11 Dwight Merriman System and method for minimizing lock contention
CN106407020A (en) * 2016-11-23 2017-02-15 青岛海信移动通信技术股份有限公司 Database processing method of mobile terminal and mobile terminal thereof
CN107391265A (en) * 2016-03-25 2017-11-24 阿里巴巴集团控股有限公司 Method and apparatus for detecting deadlock in process
CN111399911A (en) * 2020-03-24 2020-07-10 杭州博雅鸿图视频技术有限公司 Artificial intelligence development method and device based on multi-core heterogeneous computation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120131159A1 (en) * 2010-11-18 2012-05-24 International Business Machines Corporation Method and system for reducing message passing for contention detection in distributed sip server environments
US20140040220A1 (en) * 2012-07-31 2014-02-06 Hideaki Kimura Methods and systems for deadlock detection
US20140258255A1 (en) * 2013-03-11 2014-09-11 Dwight Merriman System and method for minimizing lock contention
CN107391265A (en) * 2016-03-25 2017-11-24 阿里巴巴集团控股有限公司 Method and apparatus for detecting deadlock in process
CN106407020A (en) * 2016-11-23 2017-02-15 青岛海信移动通信技术股份有限公司 Database processing method of mobile terminal and mobile terminal thereof
CN111399911A (en) * 2020-03-24 2020-07-10 杭州博雅鸿图视频技术有限公司 Artificial intelligence development method and device based on multi-core heterogeneous computation

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
党荣: "基于资源等待图的死锁检测算法", 《计算机应用与软件》, 30 June 2007 (2007-06-30), pages 1 - 3 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113691434A (en) * 2021-08-31 2021-11-23 深圳云天励飞技术股份有限公司 Data transmission system, method, electronic device, and storage medium
CN113691434B (en) * 2021-08-31 2022-09-20 深圳云天励飞技术股份有限公司 Data transmission system, method, electronic device, and storage medium
WO2023029591A1 (en) * 2021-09-03 2023-03-09 海光信息技术股份有限公司 Processor, physical register management method, and electronic apparatus
WO2024046089A1 (en) * 2022-08-31 2024-03-07 华为技术有限公司 Lock-holding process detection method and related device

Similar Documents

Publication Publication Date Title
US9740582B2 (en) System and method of failover recovery
CN107506451B (en) Abnormal information monitoring method and device for data interaction
KR102141234B1 (en) Versioned hierarchical data structure within a distributed data store
US8548945B2 (en) Database caching utilizing asynchronous log-based replication
US20190303509A1 (en) Metadata querying system
US9069832B2 (en) Approach for modularized sychronization and memory management
CN112579307A (en) Physical lock resource allocation detection method and device and electronic equipment
US8103621B2 (en) HSM two-way orphan reconciliation for extremely large file systems
US10970311B2 (en) Scalable snapshot isolation on non-transactional NoSQL
WO2013059361A1 (en) Method and system for generating domain specific in-memory database management system
CN114925084B (en) Distributed transaction processing method, system, equipment and readable storage medium
CN109951553B (en) Data processing method, system, electronic device and computer readable storage medium
US10620660B2 (en) Efficient timestamp solution for analyzing concurrent software systems
CN110990346A (en) File data processing method, device, equipment and storage medium based on block chain
US11853284B2 (en) In-place updates with concurrent reads in a decomposed state
US20140280759A1 (en) Data transmission for transaction processing in a networked environment
US10783245B2 (en) Feedback-directed static analysis
US20230161664A1 (en) Method of responding to operation, electronic device, and storage medium
CN111930684A (en) Small file processing method, device and equipment based on HDFS (Hadoop distributed File System) and storage medium
US8862544B2 (en) Grid based replication
US20230229670A1 (en) Dynamic pairing mechanism for live database replication
CN115098469A (en) Database migration method and device, electronic equipment and readable storage medium
US20210342311A1 (en) Hybrid client transaction mode for key value store
US8386732B1 (en) Methods and apparatus for storing collected network management data
US10620946B1 (en) Dynamic modeling for opaque code during static analysis

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40040790

Country of ref document: HK

SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20230914

Address after: 35th floor, Tencent building, Keji Zhongyi Road, high tech Zone, Nanshan District, Shenzhen City, Guangdong Province

Applicant after: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd.

Applicant after: TENCENT CLOUD COMPUTING (BEIJING) Co.,Ltd.

Address before: 35th floor, Tencent building, Keji Zhongyi Road, high tech Zone, Nanshan District, Shenzhen City, Guangdong Province

Applicant before: TENCENT TECHNOLOGY (SHENZHEN) Co.,Ltd.