WO2019134747A1

WO2019134747A1 - Deadlock detection and prevention

Info

Publication number: WO2019134747A1
Application number: PCT/EP2018/050178
Authority: WO
Inventors: Hillel Avni
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-01-04
Filing date: 2018-01-04
Publication date: 2019-07-11

Abstract

An apparatus for preventing deadlocks during access to a data store includes a hardware processor which: detects that a lock required for performance of an incoming data store transaction is occupied; in response to detecting the lock is occupied, performs a hardware transactional memory (HTM) transaction on a data structure mapping dependencies amongst multiple data store transactions in order to determine if placing the incoming data store transaction in a waiting state creates a deadlock; and according to the determination, instructs the incoming data store transaction whether to wait for the lock to be freed or to abort.

Description

DEADLOCK DETECTION AND PREVENTION

BACKGROUND

The present invention, in some embodiments thereof, relates to deadlock detection and prevention and, more specifically, but not exclusively, to deadlock detection and prevention using hardware transactional memory (HTM).

Some databases use exclusive locks to ensure that records are modified atomically (i.e. the transaction completes in its entirety or has no effect if aborted). A database transaction may only access a database record if it holds the lock to the records it is attempting to access. When an incoming database transaction tries to lock a record and the record is already locked, the incoming transaction enters a waiting state and does not proceed until it takes possession of the lock. A deadlock occurs when a transaction Ti enters a waiting state because a lock is held by transaction T₂, which in turn is waiting for another resource held by Ti.

One way of detecting deadlocks is a wait-for graph (WFG). The WFG tracks which other processes a given process is currently being blocked by.

Reference is now made to Fig. 1 which is a simplified example of a WFG. In the WFG of database transactions Ti, Tj and Tk, each database transaction is represented as a node. An edge from node Ti to node Tj indicates that Tj is holding a resource (e.g. lock) that Ti needs. Thus Ti must wait for Tj to release. WFG cycles (i.e. loops) imply the possibility of a deadlock. The WFG includes a cycle connecting nodes Ti-Tk, meaning that the three database transactions are in deadlock.

One known method of handling deadlocks is deadlock prevention (for example TSO[l]). Deadlock prevention allows preemption of the locks and introduces a hierarchy among transactions. The transaction hierarchy avoids waiting when a deadlock is possible. For example, upon encountering an occupied lock the symmetry is broken by comparing ID or timestamp. Alternately, transactions are aborted arbitrarily. However deadlock prevention has a high abort rate because the lock hierarchy introduces unnecessary aborts even when no deadlock actually exists.

A second method of handling deadlocks is deadlock detection and recovery (for example 2PL and MVCC [1]). Deadlock detection and recovery allows any transaction to wait for a lock, even if it creates a deadlock. While the transaction is waiting, a WFG is created and checked for loops. If a loop is found, one of the transactions in the loop is aborted according to a predefined rule. However continuous searching for deadlocks in the WFG has a high overhead and checking the WFG for a loop requires synchronization to avoid multiple detections of the same deadlock.

Additional background art includes:

[1] Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman:“Concurrency Control and Recovery in Database Systems”. Addison-Wesley 1987.

SUMMARY

Embodiments of the invention use hardware transactional memory (HTM) to detect and prevent deadlocks among transactions on a data store (for example a database). When an incoming data store transaction encounters an occupied lock it enters a waiting state.

While the incoming data store transaction is waiting, an HTM transaction is performed in order to detect whether a deadlock will be created if the incoming transaction remains in the waiting state until it may take possession of the lock. The HTM transaction detects the possibility of a deadlock by analyzing a data structure (such as a WFG) which maps dependencies amongst data store transactions.

Based on the results of the HTM transaction, the data store transaction either aborts or remains in a waiting state until it may take possession of the lock.

As used herein the term “data store” means a repository for storing and managing collections of data.

As used herein the term“data store transaction” means a collection of operations that may execute and commit changes on the data store.

As used herein the term“incoming data store transaction” means a data store transaction which is attempting to take occupancy of the lock in order to begin executing.

As used herein the term“data structure” means an organized collection of data. In the context of embodiments of the invention, the data structure is organized in a way that maps dependencies amongst data store transactions. The data structure is maintained by HTM to be consistent.

As used herein the term“HTM transaction” means a collection of operations that may execute and commit changes on the data structure in accordance with an HTM synchronization mechanism. It is an object of the present invention to provide an apparatus, a system, a computer program product, and a method for deadlock detection and prevention (DDP) for data store transactions which utilize exclusive locks.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, an apparatus for preventing deadlocks during access to a data store includes a hardware processor for:

detecting an occupancy of a lock required for performance of an incoming data store transaction to be executed on a data store;

in response to the detection of the occupancy, performing a hardware transactional memory (F1TM) transaction on a data structure mapping dependencies amongst a plurality of data store transactions to determine whether placing the incoming data store transaction in a waiting state creates a deadlock; and

instmcting the incoming data store transaction to await a freeing of the lock according to the determination.

According to a second aspect, a method for preventing deadlocks during access to a data store includes:

in response to the detection of the occupancy, performing a hardware transactional memory (F1TM) transaction on a data stmcture (230) mapping dependencies amongst a plurality of data store transactions to determine whether placing the incoming data store transaction in a waiting state creates a deadlock; and

Using a separate F1TM transaction to determine if a deadlock will occur eliminates unnecessary aborts, because transactions are only aborted if waiting will cause a deadlock. On the other hand, the overhead cost is low because the WFG is maintained consistently by F1TM and traversed only in cases where the incoming data stmcture transaction encounters an occupied lock.

In a further implementation form of the first and second aspects, the data stmcture is a wait-for graph (WFG) and a deadlock is determined when adding the incoming data structure transaction to the WFG creates a cycle. The WFG represents the dependencies amongst transactions in a simple direct manner. A potential deadlock is easily detected by traversing the graph and determining if any cycles are present when the incoming data store transaction is added to the WFG.

In a further implementation form of the first and second aspects, the incoming data store transaction is aborted if the F1TM transaction determines that placing the incoming data store transaction in a waiting state will create a deadlock. Aborting the transaction prevents the deadlock and may activate recovery mechanisms so that the incoming data store transaction will eventually be able to execute.

In a further implementation form of the first and second aspects, the F1TM transaction adds the incoming data store transaction to the data structure according to the determination of whether a deadlock will or will not be created. The data structure thus automatically remains consistent with the decision whether or not to wait for the lock.

In a further implementation form of the first aspect, the apparatus includes an F1TM module adapted to perform F1TM synchronization of the data stmcture. A dedicated F1TM module is particularly suitable for processor architectures which use dedicated modules or units (e.g. arithmetic-logic unit, load-store unit, etc.) to reduce the idle time of CPU components.

In a further implementation form of the first and second aspects, the data store is a database. The use of exclusive locks for controlling access to database records is well known in the art, making the embodiments presented herein easily implemented in a database system.

In a further implementation form of the first and second aspects, the F1TM transaction includes a single write operation directly followed by a commit operation. Thus there is only a small interval in which the F1TM may abort after the write. An F1TM transaction which has already determined whether a deadlock will or will not occur has a high chance of committing successfully.

In a further implementation form of the first and second aspects, the incoming data store transaction is performed when the lock is released. This ensures that data store transactions continue to proceed correctly, without interference by the F1TM transaction on the data structure. Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

FIG. 1 is a simplified example of a wait- for graph;

FIG. 2 is a simplified block diagram of an apparatus for preventing deadlocks during access to a data store, according to embodiments of the invention;

FIG. 3 is a simplified block diagram of a database access system with deadlock preventer in the DBMS, according to an exemplary embodiment of the invention;

FIG. 4 is a simplified flowchart of a method for preventing deadlocks during access to a data store, according to embodiments of the invention;

FIGS. 5-6 are simplified flowcharts of methods for preventing deadlocks during access to a data store, according to respective exemplary embodiments of the invention; and

FIG. 7 is a graph comparing the performance of an exemplary embodiment of the invention to the performance of the deadlock prevention and deadlock avoidance techniques. DETAILED DESCRIPTION

Embodiments of the invention use hardware transactional memory (HTM) to detect and prevent deadlocks among transactions on a data store (such as a database). Hardware transactional memory is a concurrency control mechanism which allows a group of operations on a data stmcture to execute in an atomic way.

Optionally, embodiments of the invention are implemented under the following conditions:

a) The data store uses exclusive locks to control access to data;

b) When a lock is taken it is possible to identify the data store transaction which is holding the lock; and

c) It is possible to tell if a specific data store transaction is active or committed.

In embodiments of the invention, when a transaction on a data store (denoted a data store transaction) encounters an occupied lock, the data store transaction enters a waiting state. While the data store transaction is waiting, an HTM transaction is performed in order to detect if a deadlock may be created by leaving the data store transaction in a waiting state until the lock is released. The HTM transaction detects the possibility of a deadlock by analyzing a data structure (such as a WFG) which maps dependencies amongst data store transactions. Based on the results of the HTM transaction, the data store transaction either aborts or remains in a waiting state until the lock is freed for its use.

The incoming data store transaction includes at least one operation that uses an exclusive lock. Optionally, the incoming data store transaction includes at least one read operation and/or at least one write operation. Alternately or additionally, the data store transaction includes any other type of operation which requires that the data store transaction have possession of the lock before the operation may be performed.

Embodiments of the invention are implemented to conform to the access rules/protocols/etc. of the data structure. For example, in a relational database exclusive locks may be implemented at multiple levels (e.g. file level, table level, etc.). Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instmctions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instmctions by utilizing state information of the computer readable program instmctions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instmctions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to Fig. 2, which is a simplified block diagram of an apparatus for preventing deadlocks during access to a data store, according to embodiments of the invention. Deadlock preventer 200 detects and prevents deadlocks in systems which utilize exclusive locks to control access to data records.

Deadlock preventer 200 includes at least one processor 210, and optionally a memory storing code instmctions 220 to be executed by processor 210.

When deadlock preventer 200 detects that a lock required for performance of an incoming data store transaction is occupied, deadlock preventer 200 initiates an F1TM transaction. The F1TM transaction operates on a data stmcture which maps dependencies amongst data store transactions (active and waiting).

The F1TM transaction analyzes the data stmcture to determine whether maintaining the data store transaction in a waiting state until the lock is freed for its use will or will not create a deadlock. If the F1TM transaction determines that a deadlock will be created, the data store transaction is aborted. If the F1TM transaction determines that a deadlock will not be created, the data store transaction is maintained in a waiting state until it may take occupancy of the lock.

Optionally, when the HTM transaction determines that a deadlock will not be created, the HTM transaction adds the incoming data store transaction to the data structure.

The manner in which occupancy of the lock is detected and/or how the data store transaction is placed and maintained in a waiting state and/or how the data store transaction is aborted if a potential deadlock is detected are implementation-based in accordance with constraints such as the database protocol.

Optionally, the data structure upon which the HTM transaction is performed is a wait-for graph (WFG). The HTM transaction traverses the WFG to detect cycles. If a cycle is found, the HTM transaction determines that a deadlock will be created. The incoming data store transaction is instructed to abort and is not added to the WFG. If a cycle is not found the HTM transaction determines that a deadlock will not be created, the incoming data store transaction is not instmcted to abort and maintains its waiting state.

Optionally, data structure 230 is stored on deadlock preventer 200. Data structure 230 may be stored on memory 220 along with the code instructions and/or a different internal memory in data stmcture 230. Alternately or additionally, data structure 230 is stored on an external memory (not shown).

Optionally, data stmcture 230 is stored on an external memory and is used concurrently by multiple deadlock providers. For example, when multiple database servers access the same database, each database server may have a respective deadlock preventer. The respective deadlock preventers utilize the same WFG in order to avoid deadlocks amongst data store transactions from different database servers.

Optionally, deadlock preventer 200 includes an HTM module (not shown) which performs the HTM transaction on the data stmcture and/or maintains consistency of the data stmcture so that it accurately reflects the current dependencies amongst the data store transactions.

Optionally, the HTM transaction includes a single write operation directly followed by a commit operation.

Optionally, the HTM transaction has a read only prefix, followed by a single write, followed immediately by HTM commit. Thus there is only a small interval in which the HTM may abort after the write, so an HTM transaction which finished analysis of the data structure has a high chance of committing successfully.

Optionally, the data store is a database. Further optionally the data store is a relational database.

Fig. 3 below is a simplified block diagram illustrating an exemplary embodiment of the invention in which the data store is a relational database 320 and deadlock preventer 200 is implemented as part of database management system (DBMS) 300. Relational database 320 is accessed by applications 310.1-310.h. Access to relational database 320 is managed by DBMS 300, which detects and prevents deadlocks amongst database transactions according to embodiments of the invention described herein.

Reference is now made to Fig. 4, which is a simplified flowchart of a method for preventing deadlocks during access to a data store, according to embodiments of the invention.

The method is initiated when an incoming data store transaction to be executed on a data store attempts to take control of a lock required for the performance of the incoming data store transaction. Optionally, the data store is a database (e.g. relational database).

In 410, it is detected that the lock is occupied.

In response to detecting the lock is occupied, in 420 an F1TM transaction is performed on a data structure mapping dependencies amongst the data store transactions (e.g. a WFG). The F1TM transaction determines whether placing the incoming data store transaction in a waiting state will create a deadlock.

Based on the result of the F1TM transaction, the incoming data store transaction is either instructed to wait for the lock to be freed (440) or not to wait for the lock to be freed (e.g. exit the waiting state).

Optionally, the data stmcture is a WFG. Further optionally, the F1TM transaction adds the incoming data store transaction to the WFG provisionally and traverses the WFG. If a cycle is detected, in 430 the incoming data stmcture transaction is instmcted not to wait. If a cycle is not detected, in 440 the incoming data stmcture transaction is instmcted to wait.

Optionally, when the F1TM transaction does not detect a deadlock the F1TM transaction adds the incoming data store transaction to the data stmcture so that it will remain on the data structure after the HTM transaction is completed. If a deadlock is detected, the incoming data store transaction is not added to the data structure.

Optionally, the data store transaction remains in the waiting state until the lock is freed for its use in 450. The data store transaction takes possession of the lock, and in 460 the data store transaction is performed.

Optionally, after the transaction is instmcted not to wait for the lock the data structure transaction aborts and the necessary steps are taken to recover from the abort.

Reference is now made to Fig. 5, which is a simplified flowchart of a method for preventing deadlocks during access to a data store, according to exemplary embodiments of the invention. In the embodiment of Fig. 5 the data structure is a WFG.

In 510 incoming data store transaction Tl detects that it must wait for transaction T2 (e.g. detects that a lock required for Tl to execute is occupied by T2).

In 520 Tl starts the F1TM transaction. In 530 the F1TM transaction traverses the WFG from node T2 to check that adding Tl to the WFG does not create a cycle. If a cycle is not found, the edge T1-T2 is added to the WFG, and Tl commits the F1TM transaction in 550.

In 560, if a deadlock was found Tl aborts. Otherwise Tl waits for T2 to commit and eventually takes possession of the lock, at which time Tl may execute.

Reference is now made to Fig. 6, which is a simplified flowchart of a method for preventing deadlocks during access to a data store, according to exemplary embodiments of the invention. In the embodiment of Fig. 6 the data structure is a WFG.

In 610 incoming data store transaction Tl checks whether the lock it requires is free.

If the lock is free, Tl continues execution in 620. If the lock is occupied by transaction T2, in 630 Tl starts an F1TM transaction.

The F1TM transaction traverses the WFG from the T2 node. If Tl is not reached there is no cycle and in 640 a deadlock indicator flag, DL, is set to false and the edge T1-T2 is added to the WFG. If Tl is reached there is a cycle and in 650 DL is set to false and the edge T1-T2 is not added to the WFG.

In 660 the F1TM transaction commits.

If DL is tme, Tl is aborted in 670. If DL is false, in 680 Tl waits for T2 to commit. An exemplary embodiment of code for an HTM transaction for detecting deadlocks in a WFG is:

The concurrency control allows checking if a transaction is uncommitted, i.e. live (line 6 of the code). Each ID has an entry in the graph, which holds the last transaction it was waiting for. When traversing the WFG, if the blocker is committed, the waiter is set in line 7 of the code and false is returned. Otherwise, true is returned.

If true was returned, the calling transaction must abort itself. If false was returned the calling transaction may wait safely for a finite time for the lock.

The algorithm inside the HTM transaction has a read only prefix, followed by a single write, followed immediately by HTM commit. This fits well with HTM limitations for the following reasons:

1) Higher capacity: The HTM transaction footprint is limited by Ll size, but with read-only it may reach a much higher capacity due to HW bloom filters.

2) Less conflict: As there is one writer followed by an HTM commit there is a small interval where the HTM may abort after the write, so a transaction which finished traversal has high chance to commit successfully. Reference is now made to Fig. 7, which is a graph comparing the performance of an exemplary embodiment of the invention (denoted FlTM_STE) to the performance of the deadlock prevention and deadlock avoidance techniques. As seen in Fig. 7, the performance of FlTM_STE is significantly improved over both deadlock prevention (pessimistic 2PL) and deadlock avoidance (optimistic SILO), according to the Yahoo! Cloud Serving Benchmark (YCSB) for database performance.

Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant data stores, data store transactions, exclusive lock mechanisms, databases, FlTMs, F1TM transactions, processors, and data structures will be developed and the scope of the terms data store, data store transaction, exclusive lock, database, F1TM, F1TM transaction, processor and data structure is intended to include all such new technologies a priori.

As used herein the term“about” refers to ± 10 %.

The terms“comprises”,“comprising”,“includes”,“including”,“having” and their conjugates mean“including but not limited to”. This term encompasses the terms “consisting of’ and“consisting essentially of’.

The phrase“consisting essentially of’ means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method. As used herein, the singular form“a”,“an” and“the” include plural references unless the context clearly dictates otherwise. For example, the term“a compound” or “at least one compound” may include a plurality of compounds, including mixtures thereof.

The word“exemplary” is used herein to mean“serving as an example, instance or illustration”. Any embodiment described as“exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the invention may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be constmed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases“ranging/ranges between” a first indicate number and a second indicate number and“ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be constmed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.

Claims

1. An apparatus for preventing deadlocks during access to a data store, comprising:

a hardware processor (210) for:

in response to the detection of the occupancy, performing a hardware transactional memory (HTM) transaction on a data structure (230) mapping dependencies amongst a plurality of data store transactions to determine whether placing the incoming data store transaction in a waiting state creates a deadlock; and instructing the incoming data store transaction to await a freeing of the lock according to the determination.

2. An apparatus according to claim 1, wherein the data stmcture (230) comprises a wait-for graph (WFG) and a deadlock is determined when adding the incoming data structure transaction to the WFG creates a cycle.

3. An apparatus according to claim 1 or claim 2, wherein the hardware processor (210) is further for aborting the incoming data store transaction when the F1TM transaction determines that placing the incoming data store transaction in a waiting state creates a deadlock.

4. An apparatus according to any one of claims 1-3, wherein the F1TM transaction adds the incoming data store transaction to the data stmcture (230) according to the determination.

5. An apparatus according to any one of claims 1-4, further comprising an F1TM module adapted to perform F1TM synchronization of the data stmcture (230).

6. An apparatus according to any one of claims 1-5, wherein the data store comprises a database.

7. An apparatus according to any one of claims 1-6, wherein the F1TM transaction comprises a single write operation directly followed by a commit operation.

8. A method for preventing deadlocks during access to a data store, comprising: detecting an occupancy of a lock required for performance of an incoming data store transaction to be executed on a data store;

9. A method according to claim 8, wherein the data structure (230) comprises a wait-for graph (WFG) and a deadlock is determined when adding the incoming data structure transaction to the WFG creates a cycle.

10. A method according to claim 8 or claim 9, further comprising aborting the incoming data store transaction when the F1TM transaction determines that placing the incoming data store transaction in a waiting state creates a deadlock.

11. A method according to any one of claims 8-10, adding the incoming data store transaction to the data structure (230) according to the determination.

12. A method according to any one of claims 8-11, wherein the data store comprises a database.

13. A method according to any one of claims 8-12, performing the incoming data store transaction when the lock is released.