WO2007108859A1 - Concurrency control within an enterprise resource planning system - Google Patents
Concurrency control within an enterprise resource planning system Download PDFInfo
- Publication number
- WO2007108859A1 WO2007108859A1 PCT/US2007/001021 US2007001021W WO2007108859A1 WO 2007108859 A1 WO2007108859 A1 WO 2007108859A1 US 2007001021 W US2007001021 W US 2007001021W WO 2007108859 A1 WO2007108859 A1 WO 2007108859A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- version identification
- row
- exception
- update
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C15/00—Generating random numbers; Lottery apparatus
- G07C15/005—Generating random numbers; Lottery apparatus with dispensing of lottery tickets
Definitions
- pessimistic concurrency control does not block other uses for read operations. For example, a repeatable read makes sure that the read row(s) is not updated, updated for the duration of the data transaction.
- pessimistic concurrency control places an exclusive or update lock on a data item for the duration of a data transaction, thereby preventing other users from reading the data item with the intent to update. As a result, the other users must wait for the lock to be released before reading the data item with the intent to update, which impacts the concurrency and scalability of the system.
- the scope of the lock applies to the entire database, an entire table within the database or several rows within a table rather than just the single row containing the data item being read or updated.
- the scope of the lock prevents multiple simultaneous users from reading or updating data items within different rows and/or tables.
- queries such as SQL queries
- rows are scanned and filters are applied during the evaluation of the query.
- simultaneous readers prevent each other from reading the data items even when their final query results do not intersect.
- an application may select rows and apply filters to discard selected rows based on the filter criteria, the locks that are acquired on the selected rows continue to exist for the duration of the data transaction.
- concurrent tasks may become serialized for long-lived data transactions involving shared tables, even when there is no intersection within the final set resulting from the query.
- Optimistic concurrency control allows a user to read, update and delete a data item without preventing other users from doing the same.
- Optimistic concurrency control assumes that the probability of updating or deleting the same data item during a write operation is small, and read operations are unrestricted.
- updates may be lost and only last update is maintained between the concurrent users, thereby causing data inconsistency.
- a first user may ultimately update a data item within a row of the table based on the originally retrieved values which were subsequently changed by a concurrent user. As a result, the update is based on stale data.
- the concurrency control between multiple data transactions involving the same data provides a manner in which an exception generated from the concurrency control is handled within a data transaction rather than immediately aborting the data transaction. Exceptions may be handled by re-reading and re-trying updates to the data, thereby delaying a data transaction abort.
- the concurrency control further provides options between optimistic concurrency control and pessimistic concurrency control while accounting for relative updates and inter-table dependencies. Broadly, during a data transaction involving a write request from an application, a version identification which uniquely identifies a version of the data to be updated is compared to a version identification which identifies a version of the data when the data was previously read during the same data transaction.
- the use of the concurrency control techniques is expected to de-serialize data transactions, ensure data consistency, and enable high scalability even if the data transactions are long-lived.
- FIG. 1 is a simplified and representative block diagram of a computer network
- FIG. 2 is a block diagram of a computer that may be connected to the network of Fig. 1;
- FIG. 3 is a representative block diagram of a system for managing concurrency control
- Fig.4 is a flowchart representative of a routine for optimistic concurrency control
- Fig. 5 is a flowchart representative of a routine for detecting update conflicts within the optimistic concurrency control routine of Fig. 4;
- Fig. 6 is a flowchart representative of a routine for a structured exception thrown during the detecting update conflicts routine of Fig. 5;
- Fig. 7 is a flowchart representative of a routine for handling an exception during a data transaction if an exception is thrown during the detecting update conflicts routine of Fig. 5;
- Fig. 8 is a flowchart representative of a routine for conducting a relative update of data.
- Fig. 9 is a flowchart representative of a routine for updating data dependent upon data in other tables.
- the network 10 may be the Internet, a virtual private network (VPN), or any other network that allows one or more computers, communication devices, databases, etc., to be communicatively connected to each other.
- the network 10 may be connected to a personal computer 12, and a computer terminal 14 via an Ethernet 16 and a router 18, and a landline 20.
- the Ethernet 16 may be a subnet of a larger Internet Protocol network.
- Other networked resources such as projectors or printers (not depicted), may also be supported via the Ethernet 16 or another data network.
- the network 10 may be wirelessly connected to a laptop computer 22 and a personal data assistant 24 via a wireless communication station 26 and a wireless link 28.
- a server 30 may be connected to the network 10 using a communication link 32 and a mainframe 34 may be connected to the network 10 using another communication link 36.
- the network 10 may be useful for supporting peer-to-peer network traffic.
- Fig. 2 illustrates a computing device in the form of a computer 110.
- Components of the computer 110 may include, but are not limited to a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120.
- the system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
- bus architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VES A) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
- Computer 110 typically includes a variety of computer readable media.
- Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and nonremovable media.
- Computer readable media may comprise computer storage media and communication media.
- Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
- Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, FLASH memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110.
- Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
- modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
- communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
- the system memory 130 includes computer storage media in the form of volatile andtor nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132.
- ROM read only memory
- RAM random access memory
- BIOS basic input/output system
- RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120.
- Fig. 2 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.
- the computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
- Fig. 2 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media.
- removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
- the hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
- the drives and their associated computer storage media discussed above and illustrated in Fig. 2 provide storage of computer readable instructions, data structures, program modules and other data for the computer 110.
- Fig. 2 The drives and their associated computer storage media discussed above and illustrated in Fig. 2, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110.
- hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, otherprogram modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies.
- a user may enter commands and information into the computer 20 through input devices such as a keyboard 162 and cursor control device 161, commonly referred to as a mouse, trackball or touch pad.
- a camera 163 such as web camera (webcam), may capture and input pictures of an environment associated with the computer 110, such as providing pictures of users.
- the webcam 163 may capture pictures on demand, for example, when instructed by a user, or may take pictures periodically under the control of the computer 110.
- Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through an input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
- a monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a graphics controller 190.
- computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
- the computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180.
- the remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in Fig. 2.
- the logical connections depicted in Fig. 2 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks.
- LAN local area network
- WAN wide area network
- Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
- the computer 110 When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet.
- the modem 172 which may be internal or external, may be connected to the system bus 121 via the input interface 160, or other appropriate mechanism.
- program modules depicted relative to the computer 1 10, or portions thereof may be stored in the remote memory storage device.
- Fig. 2 illustrates remote application programs 185 as residing on memory device 181.
- the communications connections 170 172 allow the device to communicate with other devices.
- the communications connections 170 172 are an example of communication media.
- the communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
- a "modulated data signal" may be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
- communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
- Computer readable media may include both storage media and communication media.
- Fig. 3 may depict an exemplary client/server network 200, such as an enterprise resource planning system, that may be similar to or coupled to the network 10 of Fig. 1.
- a clien ⁇ 'server network 200 may include individual systems 202, 204, 206, 208 coupled by networks 210, 212, 214.
- the networks 210, 212, 214 may be wired or wireless and may support Internet protocol version 6 (IPv6) and secure communications protocol, such as secured sockets layer (SSL).
- IPv6 Internet protocol version 6
- SSL secured sockets layer
- the Internet may be utilized as the networks 210, 212, 214.
- System 202 is a server system which may include one server 216 or multiple servers.
- the server system 202 may be a business enterprise server system, an SQL or other database management server system, or a messaging and enterprise collaboration server system, though different server types or server utilizations may be included.
- Systems 204, 206 are client systems that each include a network communication device 218, 220, including, but not limited to, a personal computer, telephone, a personal digital assistant, a set-top box, television, and entertainment system, and the like.
- System 208 includes a database 222 operatively coupled to the server system 202, and which stores data items.
- the database 222 may store a data item within a row of a table, and the database 222 may maintain multiple tables to store data.
- the data items may be managed by the server system 202, which are stored in various tables having one or more rows corresponding to different data items.
- the network communication devices 218, 220 may relate to different users that may engage in read and/or write operations with the server 216 to access and/or modify a data item stored within the database 222.
- the server system 202 enables multiple simultaneous users 204, 206 to read or update data items within the database 222, data items within the same table or the same data item using the concurrency control techniques described herein.
- the server 216 may enable multiple clients 204, 206 to engage a server application managed by the server system 202.
- the clients 204, 206 may execute the applications locally.
- the application may include application code that includes read and/or update statements for providing read and/or write requests.
- the term 'update' is hereby defined to mean any modification to the data item, including, but not limited to, modifying data, writing new data or deleting data.
- the client systems 204, 206 are each shown to include one network communication device 218, 220, they should be understood that different numbers of network communication devices may be utilized.
- the server system 202 may include different numbers of servers, and the database system 208 may include different numbers of databases.
- the server 216, the network communication devices 218, 220 and the database 222 are each shown to be provided within their own systems 202, 204, 206, 208, it should be understood that the server 216, the network communication devices 218, 220 and the database 222 may be provided within the same system. It should also be understood that multiple systems may be provided, including hundreds or thousands of client systems and database systems.
- the server system 202 receives a read request from an application, such as a business process, being executed by a user.
- the server system 202 may allow unrestricted read operations of data items by concurrent users, because merely reading a data item does not cause a loss of integrity.
- applications are allowed to read rows and corresponding data items without acquiring exclusive locks on the read operation, thereby allowing for maximum concurrency within the server system 202.
- read operations with the intention of updating data may also be performed without acquiring exclusive locks, thereby exposing the read operation to reading uncommitted data.
- data integrity may be maintained by comparing version identifications of the affected data during updates.
- the server system 202 may ensure data consistency to avoid lost updates.
- the data operations may be handled in three phases: a read phase, a validation phase and a write phase which actually performs the write operation.
- the server system 202 may handle the read phase
- the database 222 may handle the validation and write phases.
- Each write request is preceded by a read request.
- the write requests may be handled by receiving the initial read request, selecting the data item and providing the result to the application, when the data is being fetched from the database for subsequent updating.
- the application modifies the data item and provides the update to the server system 202 or to the database 222.
- An update lock may be initiated on the row corresponding to the data item, the data item may be selected, and the data item being updated may be validated.
- a consistency checking algorithm may be triggered which determines whether the data item was updated during another data transaction by comparing version identifications, also referred to herein as "Rec Version," of the data item as initially read and of the data item being updated. In other words, it may be determined whether the version of the data item being updated is same as the version of the data item that was initially read. If the versions are the same, the update is allowed to proceed, the changes are submitted to the database 222 and the row corresponding to the data is unlocked once the data transaction is committed.
- the server system 202 detects the conflict and raises an update conflict exception and the application is provided with an opportunity to handle the conflict to attempt to compensate for the update conflict within the data transaction without automatically rolling " back or aborting the data transaction. If the application is unable to compensate for the update conflict, the server system 202 rolls back the data transaction.
- the application may be aware of the exception and may roll back the application code to a place were the application can attempt the write operation later. The server system 202 thereby provides concurrency control during a write operation without locking the row corresponding to the data item when the data item is fetched from the database for subsequent updating.
- row-level locking is utilized during the actual update, thereby allowing other data transactions to read the data item or update any other data item within the table and/or the database 222. If the data item is modified by another data transaction between the fetch and the update, the modification is detected, and an exception is generated, handled and may be thrown from the kernel data access layer to the application code.
- the server system 202 may further maintain a pessimistic concurrency control option. Accordingly, the server system 202 may be provided with a variety of concurrency control options, including, but not limited to, globally enabling optimistic concurrency control, globally disabling optimistic concurrency control, and the enabling optimistic concurrency control for each table.
- Globally enabling optimistic concurrency control enables the kernel to conduct the data transactions under optimistic concurrency control for all tables within the database 222.
- Globally disabling optimistic concurrency control instructs the kernel to conduct the data transactions under pessimistic concurrency control for all tables within the database 222.
- a global optimistic concurrency control switch may be provided to switch between enabling and disabling the global optimistic concurrency control, and enabling or disabling, optimistic concurrency control for each table.
- the global optimistic concurrency control switch may be provided as a set flag stored within the database 222 that switches between the various options for concurrency control support.
- the server system 202 may check the status of the global optimistic concurrency control switch when the server system 202 is activated, and the global settings are fetched and stored in memory.
- the session call passes back the switch values to the client which sets the values locally.
- the per table optimistic concurrency control is added to the table property set at runtime and rendered on the application object tree property for tables.
- the per table optimistic concurrency control may use an unused bit of a flag within the metadata storage, may define the default value with a bit "0" in which case the per table optimistic concurrency control property is set to "true.”
- an application may need an exception from the configurations described above.
- optimistic concurrency control may need to be disabled at a statement level for individual applications, even though a particular table is set with optimistic concurrency control enabled for most other applications.
- the kernel may introduce key words, such as "pessimisticlock” and "optrmisticloek” described below, within the programming language to override the per table and global optimistic concurrency control switches.
- pessimisticlock and “optrmisticloek” described below
- pessimisticlock allows the kernel to not retrieve the version identification "RecVersion,” which identifies the version of the data item being updated, thereby overriding the optimistic concurrency control and allowing the data item to be read with the necessary update locks in place, according to pessimistic concurrency control.
- CustTable custTable; ; . ttsbegin; select optirnisticlock CustTable where CustTable.Currency • CAD';
- CustTable.PriceGroup TUB'; . CustTable.update(); ttscommit; >
- each data item is associated with a version identification ("Rec Version").
- Each table within the database 222 that utilizes optimistic concurrency control includes a column relating to the version identification.
- the kernel data access layer adds the version identification column to the table definition.
- a version identification column may be added to the existing tables and the server system 202 may automatically generate version identification values for all rows in the table.
- the server system 202 may automatically generate a new version identification value for the new record.
- the kernel data access layer reads the version identification values for all rows being fetched and stores the version identification values for subsequently checking the consistency of the data items to detect update conflicts.
- the kernel data access layer retrieves the version identification value for that row when it was initially fetched from the database 222 and adds it to an update statement predicate. If the update statement predicate does not find a matching version identification value, an update conflict is detected and an update conflict exception is raised to the application which attempts to handle the conflict. If the write operation involves deleting a record that was previously read, the kernel data access layer adds the version identification value to the statement predicates to determine whether the record being deleted has been previously modified.
- New version identification values generated for updated data may be maintained in the kernel data access in order to maintain the transaction semantics across multiple data operations.
- the new version identification values may be generated in the server system 202, rather than the database 222.
- the version identification may be a server timestamp that uniquely identifies the data item.
- the version identification may simply be an incrementing integer.
- read uncommitted isolation levels may be utilized, which allows data items to be selected and updated by a data transaction both within and outside of another data transaction.
- an isolation level refers to the degree to which the transaction must be isolated from other transactions.
- read uncommitted isolation levels are used to take advantage of the possibility that not all data transactions always require full isolation. As a result, data correctness may be compromised without an appropriate version identification.
- a first data transaction may read an initial version identification value V and update the data item thereby causing the version identification value to be updated to V+l.
- the first data transaction may abort the write operation, and the version identification value is reset to V.
- a second data transaction begins a write operation before the abort and reads the version identification value V+l .
- a third data transaction begins a write operation after the abort, stores the version identification value V in memory and commits the write operation before the second data transaction commits its write operation. Consequently, the third data transaction also updates the version identification value to V+l, because the version identification value V stored in memory matches the version identification value V of the data item being updated.
- the version identification may be provided as a random number that uniquely identifies the data item across all server allocations " .
- the seed for the random number may be based upon the content of the data item itself, thereby ensuring that the random number is unique to the data item across time, users and the server system 202, and each version of the data item following an update has a unique version identification value associated with it.
- the seed for the random number is a random seed used to generate the random number with a random generation algothithm.
- the generation of the random number may utilize a cryptographic application program interface, CryptGenRandom.
- the CryptGenRandom function fills a buffer with cryptographically random bytes that are more random than usual random classes.
- the measure of uncertainty i.e., entropy
- the CryptGenRandom function may be initialized once through a static method. An example of the initialization of the CryptGenRandom function is shown below.
- CRYPT_NEWKEYSET j CRYPT_MACHINE_KEYSET are used so keys for services can be access. While C++ style notation is used to describe the initialization, the initialization is not limited thereto.
- HCRYPTPROV dbRecbuf::dbrb_hCiyptProv dbRecbuf : : InitHCryptProv();
- DWORD dwError GetLastError(); AXTRACEC'hCryptProv first try acquire context failed with %d", dwError);
- ⁇ dwError GetLastError(); AXTRACE("hCryptProv second try acquire context failed with %d", dwError);
- pessimistic concurrency control may include triggers within update statements that automatically enable pessimistic locking by default.
- pessimistic locking may be triggered by a forupdate hint within SELECT and WHILE SELECT statements, and applications using a forupdate hint may work on the assumption that the server system 202 platform supports pessimistic locking.
- the optimistic concurrency control may remove, ignore or reinterpret the trigger in the update statements to disable pessimistic locking during optimistic concurrency control.
- the trigger may be reinterpreted in the context of the per statement, per table and global optimistic concurrency control switches. More specifically, the trigger may not cause an update lock to be held in the database. Instead, the trigger may specify the intention of the application. For example, the trigger may specify whether the intention is a merely a read operation or whether the intention is to use the read operation for a future update.
- the kernel data access layer may decide whether the update lock should be held (pessimistic) or if the version identification of the row should be fetched (optimistic).
- the database hint to acquire a database update lock is removed from the SELECT and WHILE SELECT statements without changing the application code for pessimistic locking.
- An example of disabling pessimistic locking is shown below by removing the database hint from SELECT and WHILE SELECT statements:
- Fig.4 is an example of an optimistic concurrency control routine 300 which may be executed by the server system 202, and in particular by the kernel data access layer of the kernel of the server system 202, to disable pessimistic locking during a write operation to update a data item within the table, where optimistic concurrency control has been enabled for a table (either globally or on a per table basis).
- each write request is preceded by a read request.
- the kernel data access layer reads the version identification values for all the corresponding rows it fetches and stores them future use, such as when an update is executed on the data items of the fetched rows.
- the kernel data access layer retrieves the version identification value for the corresponding row that was fetched from the database during the read operation, and adds the version identification value to the update statement predicates in order to see if the data item has been modified. If the update involves deleting a data item that was previously read, the kernel data access layer adds the version identification value to the update statement predicates to see if the data item being deleted has been modified. The kernel data access layer requests the database 222 to check to see if any other data transaction has changed the data item being updated after it was read. If an update conflict is detected, an UpdateConflict exception is thrown. As will be described further below, rather than immediately aborting the data transaction when the
- UpdateConflict exception is thrown, the exception may be handled within the data transaction.
- the optimistic concurrency control routine 300 receives a read request from an application during a data transaction. If the read request does not relate to a read operation with the intention of updating the row such as "forupdate,” “pessi ⁇ iisticlock,” or “optimistic lock,” as determined at block 304, any subsequent update requests received at block 306 may be disallowed at block 308 and the transaction may be terminated. If the read request relates to a read operation, with the intention of updating the row, the routine 300 may determine whether optimistic concurrency control should be applied, such as by determining if optimistic concurrency control has been enabled for the table at block 310. The routine 300 further determines at block 310 whether the version identification will be retrieved and used for the update.
- the kernel data access layer may be provided with a centralized repository for looking up calculations on whether optimistic concurrency control should be applied and whether the version identification should be retrieved. Such calculations may be performed only once on a data object, such as a data item, a row, a table or the like. In one example, such a determination may be implemented by a schema which checks to see if a version identification for a row needs to be checked using Rec Version for update and delete.
- the version identification check may not be needed or may not be used in one or more of the following situations: when Rec Version is not read, for a row set operation, if the table or a row is specifically marked as requiring a column comparison which is described further below, or if the update is a relative update which is also described further below.
- Rec Version is not read, for a row set operation, if the table or a row is specifically marked as requiring a column comparison which is described further below, or if the update is a relative update which is also described further below.
- the determination at block 312 may further be implemented by a schema which checks to see if any form of update conflict detection is to be used. For example, update conflict detection is used if the version identification is needed for the update or if a reread for the update is specified. A reread flag means that the data was originally fetched onto forms and optimistic concurrency control should be used regardless of other settings. If optimistic concurrency control is disabled, then update conflict detection may be used for forms only.
- the version identification is retrieved from the database at block 322, the update request is received at block 324 and the version identification is used for update conflict detection utilizing a detect update conflicts Toutine 326. It is noted that no update lock is implemented and held against the database at block 322.
- Fig. 5 is an example of a detect update conflicts routine 326 which may be executed by the server system 202, and in particular by the kernel data access layer of the server system 202, to detect whether or not any conflicts have occurred in updating the data item.
- the detect update conflicts routine 326 may determine whether or not the data item was changed by another data transaction between the initial fetch of the data item and the update.
- the detect update conflicts routine 326 may detect any such changes and throw an exception from the kernel data access layer to the application code.
- the detect update conflicts routine 326 may initially check to see if there is a need to perform either a version identification check (Rec Version check) or a column comparison.
- column comparison may be used if the application is merely modifying an existing data item. Column comparison may be used for backward compatibility or as application logic may dictate.
- a version identification check may be used for all forms of update, such as modifying data or deleting a data item.
- SqlStmt::AddOccExpressionNodes which first checks to see if either a version identification check or a column comparison is needed (for example, if the row was locked upon read, there is no need for either) and then switches to use either version identification or column comparison, if needed.
- routine 326 may proceed to compare columns at block 404.
- server system 202 may request the database to perform a comparison.
- the update statement utilizing column comparison may look like the following:
- the routine 326 determines that a version identification check is to be performed, the version identification is added to the update statement predicate at block 406 to determine if the data item has been modified between the fetch and the update.
- the version identification of the fetched data item is retrieved and compared to the version identification of the data item to be updated. It is noted that if the version identification comparison is to be performed by the database 222, the server system 222 does not need to fetch the version identification on behalf of the database 222. Because the version identifications are unique to the version of the data item, any difference between the version identification of the fetched data item and the version identification of the data item being updated, as detected at block 410, causes an exception to be thrown at block 412. In one example, the exception may be thrown from the kernel data access layer to the application code that generated the update statement.
- a structured exception routine may be performed as described further below, and the update conflict exception may be handled by a routine at block 414.
- the actual update of the data item is performed at block 416, which may include writing new data to the data item, deleting the data item or the like.
- a write lock also referred to as an exclusive lock
- the data transaction is committed and the write lock is released at block 420.
- Fig. 6 is an example of a structured exception routine 500 which may be executed at block 322 whenever an update conflict exception is thrown.
- the structured exception routine 500 demonstrates an example of runtime support for structured exception handling.
- a structured exception handling construct may catch an update conflict, wherein the catch lock is executed only when the update conflict happens on the table specified in the construct.
- the catch block may be executed whenever there is an update conflict exception inside a try block.
- the data access kernel may track the table instance where the update conflict exception occurred.
- the kernel may maintain a kernel representation of the table instance in which the update conflict occurred.
- the representation In C-H- programming language the representation may be referred to as the cqlCursor.
- the representation may be any variable that represents a table.
- the kernel may put the kernel representation, cqlCursor, in a table property, which may be referred to as the LastUpdateConflictingTable property, so that the kernel knows which table has incurred the update conflict exception.
- this function may be performed with the following schema, cqlDatasourceSql::RaiseU ⁇ dateConflitError, an example of which is provided below, which raises a specific error indicating an update conflict and returns an integer indicating the error code specifying the update conflict exception.
- a block 504 the routine 500 informs the user or client of the update conflict exception.
- the routine 500 sets the table property, LastUpdateConflictingTable, across the server/client call in order to set the table property properly on the client side whenever the call is made across the server/client boundary.
- the client maintains a local table property.
- any table that has incurred an UpdateConflict exception should have a local reference on the client side for the table.
- the server system 202 checks to see if there is an UpdateConflict exception, and sends the reference back to the client.
- the client sees that there is an UpdateConflict exception, reads the reference, looks the reference up locally and interprets the reference.
- the client may check the exception type and the local reference, de-reference it and set the reference on the table property.
- the structured exception routine 500 exposes the table instance that has incurred the UpdateConflict exception. For example, the
- LastUpdateConflictingTable property may be exposed to the application code on the application class.
- a run-time function enables the structured exception handling. For example, a byte code may be used as an index to a function pointer table. The function may be added to the interpret class and maps to the byte code to process the structured exception for the update conflict. At runtime, the function is called and checks both the exception type and the table on which the update conflict occurred. The function then sets the next instruction to the catch block only when they both match. Control then may pass to the handle update conflicts routine 414. [0067] Handling Update Conflict Exceptions
- Fig. 7 is an example of a handle update conflicts routine 414 shown schematically in Figs. 5 and 6, and which may be executed to handle any UpdateConflict exceptions which may occur during the detect update conflict routine 322.
- the handling of UpdateConflict exceptions may be performed within the data transaction rather than automatically aborting the data transaction when the exception occurs.
- the handle update conflicts routine 600 allows the application code to reread the data, reapply the update logic and attempt the update again.
- the handle update conflicts routine 414 described below is an exemplary depiction of compensating for an UpdateConflict exception, it should be understood that different forms of compensation logic may be utilized.
- update statements are maintained within "try" blocks, such that any exception that occurs within a try block is captured within a "catch” block.
- try blocks are nested within other try blocks thereby creating multiple try block levels.
- the handle update conflicts routine 414 enables the UpdateConflict exception to be handled within the data transaction and delays aborting the data transaction by attempting to reread and retry the data transaction within a catch block of each try block level, before moving the handling execution back to the next try block level and recapturing the UpdateConflict exception within another catch block.
- the application code may perform this whenever the conflict exception is caught and handled. More specifically, application may make sure that the data in the database and the objects state in the memory are in a consistent state.
- the data transaction may only be aborted once the outermost try block level is reached and the corresponding catch block has been executed or the transaction level has reached "0.”
- the try block level may be tracked by incrementing and decrementing a try level count, tryLevelCount, as the data transaction enters and leaves each try block.
- the try level count may be shared by the server system 202 with the client.
- a sample pseudo-computer code implementation for tracking the try block level as a data transaction enters and leaves a try block may be as follows:
- the application code may be wrapped within other application code.
- a data transaction may be nested within other data transactions.
- the UpdateConflict exception may simply be thrown to the outermost data transaction because the entire data transaction has been rolled back.
- a sample pseudo-computer code implementation for allowing the outermost is transaction to handle the UpdateConflict exception may be as follows:
- nested try blocks are supported. Rather than aborting the data transaction when an update conflict occurred, nested ttsbegin and ttscommit block may cause the nesting level to increase without starting or committing new data transactions. Rather it is included as part of an outer transaction. Transactions are started and committed by the outmost nesting level but can be aborted anywhere in the nesting. If an update conflict is raised inside a try block, the nesting level of the transaction is resorted to that when the code enters the try block. The transaction is aborted if this level is 0.
- An update conflict may be raised which may be caught using a structured exception handling construct where the catch block is executed only when the conflict happens on the table specified, or may be caught using a unstructured exception handling construct where the catch block is executed whenever an conflict occurs inside the try block.
- a mechanism that the application code may use to find out which table incurred the conflict.
- the handle update conflicts routine 414 determines whether or not the data transaction is within a try block by checking the try level counter. For example, if the try level count has a value of zero, the data transaction is no longer within a try block and may be aborted at block 606. If the data transaction is within the try block, the application code can attempt a reread and a retry of the data transaction. In particular, the catch block may attempt a predetermined number of rereads and retries before throwing the exception back to the next try block level. Thus, at block 608, the handle update conflicts routine 414 determines whether the number of retries has exceeded a predetermined limit. If so, the routine 414 throws the exception back to the next try block level at block 610.
- the routine 414 made reread the row and retry the data transaction within the catch block at block 612 without rolling back or immediately aborting the data transaction. If the UpdateConflict exception is successfully handled, as determined at block 614, a corresponding information log regarding the
- UpdateConflict exception may be cleared at block 616 and the data transaction may be committed.
- An UpdateConflict exception may be successfully handled, for example, by rereading the data from the database and retrying the update. In such a case, the update lock is not held in the database, but the application can choose to switch to pessimistic locking in the handling code, in which case the update lock is held through the read and updated to an exclusive lock after the update. If the UpdateConflict exception is not successfully handled, the retry count may be incremented by one and control may pass back to block 608.
- a sample pseudo-computer code implementation for handling the UpdateConflict exception may be as follows.
- the try catch level is one and no more than five retries are allowed.
- a sample pseudo-computer code implementation for handling an UpdateConflict exception with multiple updates may be as follows. As demonstrated by the pseudo-computer code, the update conflict encountered by a first application results in the data transaction being aborted as dictated by the application code. On the other hand, the update conflict encountered by the second application results in a retry. static void Occ2Test_MultipleUpdateConflictMgmt(Args _args)
- cust2.CreditRating strftnt("%r i ,str2int(cust2.CreditRating)+l); cust2.update0;
- update tablel set fieldl fieldl + change
- update tablel set fieldl fmalValue
- the relative update decrements causes the initial value to be decremented by two in response to the first data transaction, and decrements the new value by two again in response to the second data transaction to provide a final value of "four."
- Fig. 8 is an example of a relative update routine 700 which may be used to perform relative updates on the date item.
- the relative update routine 700 determines whether or not the update statement calls for a relative update and/or whether or not the field being updated is marked as using relative updates. If the update is not a relative update, control may refer back to the optimistic concurrency control routine 300.
- a pseudo-computer code example is provided below for determining whether a relative update may the utilized. As mentioned, because version identifications are not utilized, fields associated with the version identification are ignored. void SqlStmt::SetIsRelativeUpdate(boolean flsRelativeUpdate)
- Transaction semantics should be maintained where potentially multiple references to the same row in a table can be held and multiple operations can be performed on the multiple references.
- the version identifications on variables holding references to the same row being updated are updated as if they were read in the same transaction.
- Rec Versiona two other columns may be added: TransactionRecVersiona and
- the routine 700 may update the value identification for the updated field.
- the relative update routine 700 does not check the value identification, the possibility exists that the update may overwrite another data transactions update if the value identification is updated with new value using the techniques described above, as illustrated by the chart below:
- a first data transaction may read the initial version identification value V and update the data item thereby causing the version identification value to be updated to Vl .
- a second data transaction begins a write operation before the update, and performs two updates, with a first update being a relative update and a subsequent second update being an absolute update.
- the first update of the second data transaction does not check the version identification value Vl because the update is a relative update. Nonetheless, the first update provides new version identification value V2.
- the second update of the second data transaction gets the version identification value V2 during the read, uses the version identification value V2 upon update, updates the data item and successfully commits the data transaction because the version identification value V2 during the update matches the version identification value V2 initially read before the second update.
- the new version identification is calculated as a relative version identification when the update is performed as relative update.
- the routine 700 computes the new value for the version identification as provided above at block 704.
- the update is performed at block 710.
- the version identification is updated using the difference as well.
- values of some columns within a table may be calculated based on upon values some columns of another table (e.g., table B). For example, an update to a data item within table A may initially read a value from table B, but prior to updating the data item within table A another user updates the value of table B. As result, the subsequent update to the data item within table A is based upon a stale value from table B.
- the kernel data access layer may supply a repeatable read hint for the application code.
- the repeatable read hint translates into a repeatable read lock hint, RepeatableRead, to the server system 202 which holds a shared lock on the fetched data until the data transaction ends.
- the repeatable read lock hint is applied only to the specific read statement and not to the entire data transaction.
- the shared lock is released right after the read operation. This may prevent other users from updating the row until the data transaction is committed.
- the shared locks are compatible with each other, such that multiple users running the same script are not blocked from each other.
- Fig. 9 is an example of an inter-table dependency routine 800 which may be used to updated data item dependent upon a value from another table.
- the routine 800 may receive a repeatable read hint from the application code which translates into the repeatable read lock hint to the server system 202.
- the shared lock is released immediately following the read operation at block 804 and the transaction is committed.
- a repeatable read hint is provided, a shared locked on both table A and table B for the fetched data is provided at block 806 for the duration of the data transaction to prevent other users from updating the data item until the transaction is committed.
- the data item is fetched from table B at block 808.
- the data item for table A is calculated based on the updated data item from table B and updated at block 812.
- the shared lock is released and the data transaction is committed.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP07716630A EP2011045A1 (en) | 2006-03-17 | 2007-01-16 | Concurrency control within an enterprise resource planning system |
BRPI0708732-2A BRPI0708732A2 (en) | 2006-03-17 | 2007-01-16 | concurrency control within an entrepreneurial resource planning system |
CN2007800094223A CN101405735B (en) | 2006-03-17 | 2007-01-16 | Concurrency control within an enterprise resource planning system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/378,890 | 2006-03-17 | ||
US11/378,890 US7933881B2 (en) | 2006-03-17 | 2006-03-17 | Concurrency control within an enterprise resource planning system |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2007108859A1 true WO2007108859A1 (en) | 2007-09-27 |
Family
ID=38519162
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2007/001021 WO2007108859A1 (en) | 2006-03-17 | 2007-01-16 | Concurrency control within an enterprise resource planning system |
Country Status (7)
Country | Link |
---|---|
US (1) | US7933881B2 (en) |
EP (1) | EP2011045A1 (en) |
KR (1) | KR20080106431A (en) |
CN (1) | CN101405735B (en) |
BR (1) | BRPI0708732A2 (en) |
RU (1) | RU2417427C2 (en) |
WO (1) | WO2007108859A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017131784A1 (en) * | 2016-01-29 | 2017-08-03 | Hewlett Packard Enterprise Development Lp | Hybrid concurrency control |
Families Citing this family (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7818740B2 (en) * | 2006-05-05 | 2010-10-19 | Microsoft Corporation | Techniques to perform gradual upgrades |
US7571165B2 (en) * | 2006-09-28 | 2009-08-04 | Sap Ag | Method and system for providing locking behavior |
US8041692B2 (en) * | 2007-04-09 | 2011-10-18 | Hewlett-Packard Development Company, L.P. | System and method for processing concurrent file system write requests |
US8091094B2 (en) | 2007-10-10 | 2012-01-03 | Sap Ag | Methods and systems for ambistateful backend control |
US7895172B2 (en) * | 2008-02-19 | 2011-02-22 | Yahoo! Inc. | System and method for writing data dependent upon multiple reads in a distributed database |
US8914341B2 (en) * | 2008-07-03 | 2014-12-16 | Tripwire, Inc. | Method and apparatus for continuous compliance assessment |
US8073778B2 (en) | 2008-09-11 | 2011-12-06 | Linden Research, Inc. | Scalable distributed transaction manager for multi-host transactions |
US8332443B2 (en) * | 2008-12-19 | 2012-12-11 | Microsoft Corporation | Masterless distributed batch scheduling engine |
US8719845B2 (en) | 2010-05-19 | 2014-05-06 | Microsoft Corporation | Sharing and synchronization of objects |
US8768902B2 (en) | 2010-06-11 | 2014-07-01 | Microsoft Corporation | Unified concurrent changes to data, schema, and application |
US8386421B2 (en) | 2010-06-28 | 2013-02-26 | Microsoft Corporation | Concurrency control for confluent trees |
US8412689B2 (en) * | 2010-07-07 | 2013-04-02 | Microsoft Corporation | Shared log-structured multi-version transactional datastore with metadata to enable melding trees |
CN102456017A (en) * | 2010-10-18 | 2012-05-16 | 北京市金蝶政务软件有限公司 | Data storage method and device |
US9848106B2 (en) | 2010-12-21 | 2017-12-19 | Microsoft Technology Licensing, Llc | Intelligent gameplay photo capture |
US9003519B2 (en) * | 2011-05-16 | 2015-04-07 | At&T Intellectual Property I, L.P. | Verifying transactions using out-of-band devices |
CN102436633A (en) * | 2011-11-30 | 2012-05-02 | 华为技术有限公司 | Data management method and system as well as database system |
US9110940B2 (en) | 2012-02-29 | 2015-08-18 | Red Hat, Inc. | Supporting transactions in distributed environments using a local copy of remote transaction data and optimistic locking |
US8832050B2 (en) * | 2012-03-09 | 2014-09-09 | Hewlett-Packard Development Company, L.P. | Validation of distributed balanced trees |
US9774676B2 (en) | 2012-05-21 | 2017-09-26 | Google Inc. | Storing and moving data in a distributed storage system |
US9449006B2 (en) | 2012-06-04 | 2016-09-20 | Google Inc. | Method and system for deleting obsolete files from a file system |
US9230000B1 (en) | 2012-06-04 | 2016-01-05 | Google Inc. | Pipelining Paxos state machines |
WO2013184712A2 (en) | 2012-06-04 | 2013-12-12 | Google Inc. | Systems and methods of increasing database access concurrency using granular timestamps |
US9659038B2 (en) | 2012-06-04 | 2017-05-23 | Google Inc. | Efficient snapshot read of a database in a distributed storage system |
US20140067480A1 (en) * | 2012-09-05 | 2014-03-06 | Rocket Software, Inc. | Systems and methods for enterprise-level context management |
CN104239357B (en) * | 2013-06-21 | 2019-01-18 | Sap欧洲公司 | Concurrent request processing for db transaction |
US9659050B2 (en) | 2013-08-06 | 2017-05-23 | Sybase, Inc. | Delta store giving row-level versioning semantics to a non-row-level versioning underlying store |
US9489409B2 (en) | 2013-10-17 | 2016-11-08 | Sybase, Inc. | Rollover strategies in a N-bit dictionary compressed column store |
US10282228B2 (en) * | 2014-06-26 | 2019-05-07 | Amazon Technologies, Inc. | Log-based transaction constraint management |
CN104573833A (en) * | 2014-12-31 | 2015-04-29 | 普天新能源有限责任公司 | Charging ordering method |
US9679003B2 (en) * | 2015-01-07 | 2017-06-13 | International Business Machines Corporation | Rendezvous-based optimistic concurrency control |
US10489374B2 (en) | 2015-06-01 | 2019-11-26 | International Business Machines Corporation | In-place updates with concurrent reads in a decomposed state |
US9514046B1 (en) | 2015-06-10 | 2016-12-06 | International Business Machines Corporation | Dynamic detection and software correction of incorrect lock and atomic update hint bits |
US9921953B2 (en) | 2015-09-09 | 2018-03-20 | International Business Machines Corporation | Dynamic detection and correction of incorrect lock and atomic update hint bits |
JP2017078981A (en) * | 2015-10-21 | 2017-04-27 | 富士通株式会社 | Exclusion switching program and exclusion switching method |
CN106921646B (en) * | 2016-07-26 | 2020-11-20 | 创新先进技术有限公司 | Service processing method and device |
CN106919640A (en) * | 2016-11-16 | 2017-07-04 | 阿里巴巴集团控股有限公司 | A kind of method and device for business processing |
CN106776052B (en) * | 2016-12-07 | 2019-12-10 | 金蝶软件(中国)有限公司 | Shared resource access method and device |
US10810188B2 (en) * | 2017-11-29 | 2020-10-20 | Teradata Us, Inc. | Load committed isolation processing |
US11423003B2 (en) | 2017-12-11 | 2022-08-23 | Micro Focus Llc | Optimistic concurrency control for database transactions |
CN108769260B (en) * | 2018-06-29 | 2020-10-16 | 苏州浪潮智能科技有限公司 | Event processing method and device in cluster upgrading process |
US11023445B2 (en) * | 2018-07-24 | 2021-06-01 | Sap Se | Optimistic concurrency for collaborative applications |
US11640383B2 (en) * | 2018-11-15 | 2023-05-02 | Huawei Technologies Co., Ltd. | Systems and methods for managing a shared database |
FR3090929B1 (en) * | 2018-12-20 | 2021-07-02 | Amadeus Sas | Refresh multiple data records |
US11347713B2 (en) * | 2019-09-27 | 2022-05-31 | Salesforce.Com, Inc. | Version-based table locking |
CN110765143B (en) | 2019-10-10 | 2022-08-02 | 腾讯科技(深圳)有限公司 | Data processing method, device, server and storage medium |
CN112596866B (en) * | 2020-12-28 | 2024-09-03 | 北京浪潮数据技术有限公司 | Concurrency control method, device, equipment and medium for concurrency processing request |
CN115098228B (en) * | 2021-05-19 | 2023-04-14 | 腾讯科技(深圳)有限公司 | Transaction processing method and device, computer equipment and storage medium |
US12061587B2 (en) | 2022-06-13 | 2024-08-13 | Snowflake Inc. | Query processing using hybrid table secondary indexes |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5263156A (en) | 1990-12-20 | 1993-11-16 | Bell Communications Research, Inc. | Parallel, distributed optimistic concurrency control certification using hardware filtering |
US5857197A (en) | 1997-03-20 | 1999-01-05 | Thought Inc. | System and method for accessing data stores as objects |
US5920857A (en) | 1997-08-04 | 1999-07-06 | Naphtali Rishe | Efficient optimistic concurrency control and lazy queries for B-trees and other database structures |
US6125371A (en) * | 1997-08-19 | 2000-09-26 | Lucent Technologies, Inc. | System and method for aging versions of data in a main memory database |
US6249803B1 (en) * | 1997-12-18 | 2001-06-19 | Sun Microsystems, Inc. | Method and apparatus for executing code during method invocation |
US6240413B1 (en) | 1997-12-22 | 2001-05-29 | Sun Microsystems, Inc. | Fine-grained consistency mechanism for optimistic concurrency control using lock groups |
US6195685B1 (en) | 1998-05-22 | 2001-02-27 | International Business Machines Corporation | Flexible event sharing, batching, and state consistency mechanisms for interactive applications |
US6338086B1 (en) | 1998-06-11 | 2002-01-08 | Placeware, Inc. | Collaborative object architecture |
US6363387B1 (en) | 1998-10-20 | 2002-03-26 | Sybase, Inc. | Database system providing methodology for enhancing concurrency using row update bit and deferred locking |
US6636242B2 (en) * | 1999-08-31 | 2003-10-21 | Accenture Llp | View configurer in a presentation services patterns environment |
US6598041B1 (en) | 2000-09-07 | 2003-07-22 | International Business Machines Corporation | Method, system, and program for processing modifications to data in tables in a database system |
US6681226B2 (en) | 2001-01-30 | 2004-01-20 | Gemstone Systems, Inc. | Selective pessimistic locking for a concurrently updateable database |
US6928582B2 (en) * | 2002-01-04 | 2005-08-09 | Intel Corporation | Method for fast exception handling |
US7139690B2 (en) * | 2002-07-22 | 2006-11-21 | Microsoft Corporation | Object-level conflict detection in an object-relational database system |
US7827135B2 (en) | 2002-12-31 | 2010-11-02 | International Business Machines Corporation | Method and apparatus for relaxed transactional isolation in a client-server caching architecture |
US7290015B1 (en) * | 2003-10-02 | 2007-10-30 | Progress Software Corporation | High availability via data services |
US7599908B2 (en) * | 2005-11-18 | 2009-10-06 | Sap Ag | Logical locking for Java Data Objects |
-
2006
- 2006-03-17 US US11/378,890 patent/US7933881B2/en not_active Expired - Fee Related
-
2007
- 2007-01-16 CN CN2007800094223A patent/CN101405735B/en not_active Expired - Fee Related
- 2007-01-16 EP EP07716630A patent/EP2011045A1/en not_active Withdrawn
- 2007-01-16 WO PCT/US2007/001021 patent/WO2007108859A1/en active Application Filing
- 2007-01-16 KR KR1020087022484A patent/KR20080106431A/en not_active Application Discontinuation
- 2007-01-16 BR BRPI0708732-2A patent/BRPI0708732A2/en not_active IP Right Cessation
- 2007-01-16 RU RU2008137135/08A patent/RU2417427C2/en not_active IP Right Cessation
Non-Patent Citations (4)
Title |
---|
BHARAT BHARGAVA: "Concurrency Control in Database Systems", KNOWLEDGE AND DATA ENGINEERING, IEEE TRANSACTIONS, vol. 11, no. 1, January 1999 (1999-01-01), pages 3 - 16, XP008129262 * |
DELANEY K. AND GUERRERO F.: "Database concurrency and row level versioning in SQL server 2005", MICROSOFT CORPORATION, 30 April 2005 (2005-04-30), XP002352001 * |
NEKRESTYANO ET AL.: "Concurrency Control Protocols for Persistent Shared Virtual Memory Systems", PROC. OF THE WORKSHOP ON ADVANCES IN DATABASES AND INFORMATION SYSTEMS, ADBIS'97, ST.-PETERSBURG, 2 September 1997 (1997-09-02) - 5 September 1997 (1997-09-05), pages 035 - 039, XP008129261 * |
SEIFERT A. AND SCHOLL M.H.: "Processing Read-only Transactions in Hybrid Data Delivery Environments with Consistency and Currency Guarantees", MOBILE NETWORKS AND APPLICATION, vol. 8, 2003, pages 327 - 342, XP001503558 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017131784A1 (en) * | 2016-01-29 | 2017-08-03 | Hewlett Packard Enterprise Development Lp | Hybrid concurrency control |
US11080261B2 (en) | 2016-01-29 | 2021-08-03 | Hewlett Packard Enterprise Development Lp | Hybrid concurrency control |
Also Published As
Publication number | Publication date |
---|---|
RU2417427C2 (en) | 2011-04-27 |
US20070219999A1 (en) | 2007-09-20 |
US7933881B2 (en) | 2011-04-26 |
KR20080106431A (en) | 2008-12-05 |
CN101405735B (en) | 2011-12-14 |
CN101405735A (en) | 2009-04-08 |
EP2011045A1 (en) | 2009-01-07 |
RU2008137135A (en) | 2010-03-27 |
BRPI0708732A2 (en) | 2011-06-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7933881B2 (en) | Concurrency control within an enterprise resource planning system | |
US11314716B2 (en) | Atomic processing of compound database transactions that modify a metadata entity | |
KR101099199B1 (en) | System and method for a snapshot query during database recovery | |
US7761434B2 (en) | Multiversion concurrency control in in-memory tree-based data structures | |
US7702660B2 (en) | I/O free recovery set determination | |
US7606838B2 (en) | Distributed conflict resolution for replicated databases | |
US8266122B1 (en) | System and method for versioning data in a distributed data store | |
JP4890811B2 (en) | Validate dynamically generated operations against the data store | |
US20160179865A1 (en) | Method and system for concurrency control in log-structured merge data stores | |
US7895172B2 (en) | System and method for writing data dependent upon multiple reads in a distributed database | |
US7653665B1 (en) | Systems and methods for avoiding database anomalies when maintaining constraints and indexes in presence of snapshot isolation | |
JP4759570B2 (en) | Techniques for providing locks for file operations in database management systems | |
US20060271606A1 (en) | Version-controlled cached data store | |
JP2008538632A (en) | System and method for manipulating data in a data storage system | |
US20090319581A1 (en) | Online Table Move | |
US12032560B2 (en) | Distributed transaction execution management in distributed databases | |
US11507566B2 (en) | Managing objects in shared caches using multiple chains | |
US20080177959A1 (en) | System and method for executing transactions | |
US20090187599A1 (en) | Generating identity values in a multi-host database management system | |
US11720607B2 (en) | System for lightweight objects | |
US11372571B2 (en) | System and methods for providing a memory slice data structure for use with diverse memory and storage media | |
US9772842B2 (en) | Managing change sets | |
US7860848B2 (en) | Partial sub-lock for delta object management | |
CN117076147B (en) | Deadlock detection method, device, equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07716630 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 4393/CHENP/2008 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020087022484 Country of ref document: KR |
|
ENP | Entry into the national phase |
Ref document number: 2008137135 Country of ref document: RU Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200780009422.3 Country of ref document: CN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2007716630 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref document number: PI0708732 Country of ref document: BR Kind code of ref document: A2 Effective date: 20080909 |