WO2016148716A1 - Envoi de transaction incertaine à une unité de notification - Google Patents

Envoi de transaction incertaine à une unité de notification Download PDF

Info

Publication number
WO2016148716A1
WO2016148716A1 PCT/US2015/021410 US2015021410W WO2016148716A1 WO 2016148716 A1 WO2016148716 A1 WO 2016148716A1 US 2015021410 W US2015021410 W US 2015021410W WO 2016148716 A1 WO2016148716 A1 WO 2016148716A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
unit
doubt
data store
notice
Prior art date
Application number
PCT/US2015/021410
Other languages
English (en)
Inventor
Shang-Sheng Tung
Sean L. BROEDER
Oliver BUCAOJIT
John Deroo
Narendra Goyal
Trina R. Wisler-Krug
Adriana C. FUENTES
Ronald M. Cassou
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Priority to PCT/US2015/021410 priority Critical patent/WO2016148716A1/fr
Publication of WO2016148716A1 publication Critical patent/WO2016148716A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1474—Saving, restoring, recovering or retrying in transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • FIG. 1 is an example block diagram of a system to post an in-doubt transaction to a notice unit
  • FIG. 2 is another example block diagram of a system to post an in-doubt transaction to a notice unit
  • FIG. 3 is an example block diagram of a computing device including instructions for posting an in-doubt transaction to a notice unit;
  • FIG. 4 is an example flowchart of a method for posting an in-doubt transaction to a notice unit.
  • Data stores usually have their own processes to recover from a crash (e.g. HBase utilizes the HLOG to perform row-level WAL). For a transaction spanning across multiple data stores, this may generally require a transaction manager (TM) to coordinate the transaction commit processing and resolve any in- doubt transaction if failures occur.
  • TM transaction manager
  • RM resource manager
  • TDS Transactional Data Store
  • a transaction spanning multiple stores could be committed in some data stores, but may be un-deterministic in other data stores (e.g. due to message being lost, process/node failure, system crash) and require a coordination between the TM and the RM (within the TDS) to resolve it.
  • the TM is asked to perform recovery on all the known TDSs (such as via a full broadcast) during restart, or the TM is asked to keep track of the TDSs and to monitor if there is a failure or an exception and then try to recover them.
  • These requirements usually ask the TM to perform additional work and degrade the efficiency in transaction processing (e.g. usually latency may increase), in addition, it may also restrict the flexibility of TDS to relocate, split, or move for performance, capacity, or failure consideration.
  • the number of transactional data stores and its server location could be changed dynamically. So it may be complicated to have the TM broadcast the recover request to ail the transactional data stores or monitor the status of entire data stores.
  • the number of RMs within the transactional data store
  • running recovery against all the regions from all the TMs might not be very efficient,
  • the TM initiates the system recovery.
  • the TM collects a list of all the configured RMs and broadcasts the recover requests to ail of them.
  • Each individual RM exercises its own recovery mechanism (e.g. perform REDO (audit replay) to reconstruct the before-crash-image, including missing data writes and in-doubt (and in-flight) transactions).
  • This in-doubt transaction list is then replied back to the TM.
  • the TM will determine the outcome of each in-doubt transaction, and then drive the 2nd phase of commit processing to resolve the in-doubt transactions (either commit or abort). After all the in-doubt transactions have completely resolved (committed or rolled-back), system is recovered and then new transactions can be started.
  • examples may provide a pulling approach to perform transactional recovery in a large scale distributed data store (SQL or NOSQL) against failures, such as via a registration-based mechanism that has the RM inform the TM if the RM decides it has questions at hand (e.g. a need to resolve an in-doubt transaction from crash, or a need to check why a prepared transaction branch stays too long).
  • SQL large scale distributed data store
  • examples may resolve the inefficiency and the complexity traditional recovery encountered under the environment of large data stores. This approach may provide better scalability and extensibility in a large data store since the number of RMs could be very large and the set of R s could be dynamic (e.g. due to automatic data sharding for load balance, capacity, or elasticity).
  • recovery information may be posted to a notice unit by a data store unit to indicate that a commitment of a transaction is in-doubt at the data store unit.
  • a transaction unit may monitor the recovery information at the notice unit.
  • the transaction unit may indicate to the data store unit to one of commit and abort the in-doubt transaction, if the transaction unit determines there is recovery information related to the in-doubt transaction at the notice unit.
  • examples may be more scalable and have a better capability to manage a very large number of data stores across the distributed environment. Also, examples may be idempotent in that they may handle repeated failure during recovery. Further, examples may handle multiple failures in a distributed way. Examples may not need to have a centralized TM to synchronize or coordinate the transaction processing or perform recovery. Since there is no need for centralized transactional control, this may yield better performance, and it may be easier to manage possible splitting issues on transaction commit processing, in addition, examples may not require the TM to monitor the status of the entire system.
  • Examples may use a no-waited protocol, which may reduce any inefficiency introduced by traditional recovery scheme. By using a demand-driven approach, examples may reduce the number of messages transmitted. Examples may provide a uniform infrastructure for transactional recovery against several types of failures like data server process failure, node failure, TM failure, or system crash.
  • FIG. 1 is an example block diagram of a system 100 to post an in-doubt transaction to a notice unit.
  • the system 100 may include a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, a storage device or any other type of device capable of interacting with a device in a distributed network.
  • the system 100 is shown to include a notice unit 1 10 and a transaction unit 120.
  • the notice and transaction units 1 10 and 120 may include, for example, a hardware device including electronic circuitry for implementing the functionality described below, such as control logic and/or memory.
  • the notice and transaction units 1 10 and 120 may be implemented as a series of instructions encoded on a machine-readable storage medium and executable by a processor.
  • the notice unit 1 10 may store recovery information 1 12.
  • the recovery information 1 12 may be posted to the notice unit 1 10 by at least one of a plurality of data store units to indicate that a commitment of a transaction is in-doubt at the at least one data store unit.
  • the transaction unit 120 may monitor the recovery information 1 12 at the notice unit 1 10.
  • the transaction unit 120 may indicate to the at least one data store unit to one of commit and abort the in-doubt transaction 1 14, if the transaction unit 120 determines there is recovery information 1 12 related to the in-doubt transaction 1 14 at the notice unit 1 10.
  • the notice 1 10 and transaction units 1 10 and 120 are described in further detail below with respect to FIG. 2.
  • FIG. 2 is another example block diagram of a system 200 to post an in- doubt transaction to a notice unit.
  • the system 200 may include a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an ail-in-one system, a server, a network device, a wireless device, a storage device or any other type of device capable of interacting with a device in a distributed network.
  • the system 200 of FIG. 2 may include at least the functionality and/or hardware of the system 100 of FIG. 1 ,
  • the system 200 is shown to include a notice unit 210 and a transaction unit 220.
  • the notice unit 210 of the system 200 of FIG. 2 may include at least the functionality and/or hardware of the notice unit 1 10 of the system 100 of FIG. 1 and the transaction unit 220 of the system 200 of FIG. 2 may include at least the functionality and/or hardware of the transaction unit 120 of the system 100 of FIG. 1.
  • the system 200 is also shown to include a plurality of data store units 232-1 to 232-n, where n is a natural number.
  • a data store unit 232 may include a repository of a set of data objects. These objects may be modelled using classes defined in a database schema.
  • the data store unit 232 may include not only repositories like databases, but also simpler store types such as flat files etc.
  • the data stores units 232 may include, for example, simple files like a spreadsheet, file systems, email storage systems (both server and client systems), databases, relational databases such as MySQL, PostgreSQL, Microsoft SQL Server, and Oracle Database, Object-oriented databases such as Cache or ConceptBase, distributed data stores such as Apache Cassandra, Druid (open-source data store) and Dynamo, directory services, and a file that stores a virtual machine.
  • the data store units 232 include any electronic, magnetic, optical, or other physical storage device that contains or stores information, such as Random Access Memory (RAM), an Electrically Erasable Programmable Readonly Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. Further, each of the data store units 232 may include one or more TDS, which may further include one or more RMs.
  • An example of an RM might be a database (like Oracle, DB2, SQL Server) or a transactional message queue (like IBM MQSeries or Microsoft Message Queue).
  • Transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it can never be only partially complete.
  • a transaction comprises a unit of work performed within a database management system (or similar system) against a database, and treated in a coherent and reliable way independent of other transactions.
  • a transaction generally represents any change in database.
  • a distributed transaction is a database transaction in which two or more network hosts are involved.
  • hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources.
  • Distributed transactions as any other transactions, have all four ACID (atomicity, consistency, isolation, durability) properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle).
  • the consistency property ensures that any transaction will bring the database from one valid state to another, e.g. only change affected data in allowed ways.
  • the isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other.
  • Durability means that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently (even if the database crashes immediately thereafter). To defend against power loss, transactions (or their effects) must be recorded in a non-volatile memory. Durability can be achieved by flushing the transaction's log records to non-volatile storage before acknowledging commitment. [0026] In distributed transactions, all participating servers must coordinate before commit can be acknowledged.
  • the 2PC may be any type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction (it is a specialized type of consensus protocol). The protocol achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures).
  • ACP atomic commitment protocol
  • a single transaction can update many different databases or resources, and these resources may be distributed across networks, and have independent availability and failure modes.
  • the two-phase commit strategy is designed to ensure that either all the resources are updated or none of them, so that the resources under transactional control remain synchronized.
  • the two-phase commit protocol requires a coordinator to maintain aii the information needed to recover the original state of the database if something goes wrong. As the name indicates there are two phases, voting and commit.
  • each node e.g. participant, cohort or worker
  • the nodes then report their status to the coordinator, if any node does not report to the coordinator or their status message is lost the coordinator assumes the node's write failed.
  • the second phase begins.
  • the coordinator sends a commit message to each of the nodes to record in their individual logs. Until this message is added to a node's log, any changes made will be recorded as incomplete, if any of the nodes reported a failure the coordinator will instead send a rollback message. This will remove any changes the nodes have written to disk.
  • the notice unst 210 may store recovery information 1 12.
  • the recovery information 1 12 may be posted to the notice unit 1 10 by at least one of a plurality of data store units 232-1 to 232-n to indicate that a commitment of a transaction 234 is in-doubt at the at least one data store unit 232-1.
  • the in-doubt transaction 234 at one of the data store units 232-1 may be part of a transaction distributed among a plurality of the data store units 232-1 to 232-n.
  • the at least one data store unit 232-1 may identify the in-doubt transaction based on at least one of a crash, failure and delayed branch.
  • the at least one data store unit 232-1 may reconstruct a state of the delayed branch based on at least one of a transaction identification number, an identity of the transaction unit 220, an undo log and a redo log.
  • the at least one data store unit 232-1 may store the recovery information 1 12 relating to the in-doubt transaction 234 to the notice unit 210 only if the recovery information 1 12 of the data store unit 232-1 is not posted at the notice unit 210.
  • the first data store unit 232-1 may first check if the transaction 234 is posted as being in-doubt at the first data store unit 232-1 before posting the in-doubt transaction 234 to the notice unit 210.
  • the transaction unit 220 may monitor the recovery information 1 12 at the notice unit 210.
  • the transaction unit 220 may request to the data store unit 232-1 that stored the recovery information 210 to the notice unit 210 to provide any in-doubt transactions 234 at the data store unit 232-1 .
  • the transaction unit 220 may add any in-doubt transactions 234 related to recovery information 1 12 posted at the notice unit 210 to an in-doubt transaction list 222. For instance, the transaction unit 220 may receive three additional in-doubt transactions 234 for the first data store unit 232-1 , which are then added to the in-doubt transaction list 222.
  • the transaction unit 220 may request any in-doubt transactions 234 from each of the data store units associated with each of the in-doubt transactions 234 of the in-doubt transaction list 222.
  • the transaction unit 220 may request ail in-doubt transactions 234 from each of the data store units 232 associated with an in-doubt transaction 234 of the in-doubt transaction list 222, to have a more complete list of ail in-doubt transactions 234. These in- doubt transactions 234 are replied back to the transaction unit 220.
  • the transaction unit 220 may build a transaction state table 224 based on a response from each of the data store units 232-1 to 232-n to the request for any in-doubt transactions 234.
  • the transaction state table 224 may determine any in-doubt distributed transactions based on a plurality of the data store units 232-1 to 232-n reporting a same transaction as being in-doubt in response to the request. For example, assume that the transaction unit 220 previously carried out three distributed transactions.
  • the transaction state table 224 may reflect the following states: the first distributed transaction may be in-doubt at the first and third data store units 231 -1 and 232-3, the second distributed transaction may be in-doubt at the second data store unit 232-2 and the third distributed transaction may be in-doubt at the fourth, fifth and sixth data store units 232-4, 232-5 and 232-6, [0036]
  • the transaction unit 220 may read a persistent transaction state log 226 to determine an outcome for each of the in-doubt distributed transactions of the transaction state table 224.
  • the persistent transaction state log 226 may record a decision of the transaction unit 220 for previous transactions distributed among a plurality of data store units.
  • the transaction unit 220 may indicate to commit the in-doubt transaction 234 to the at least one data store unit 232-1 , if the persistent transaction state log 226 includes an entry to commit the in-doubt distributed transaction.
  • the transaction unit 220 may indicate to abort the in-doubt transaction 234 to the at least one data store unit 232-1 , if the persistent transaction state iog 226 does not include an entry to the in-doubt distributed transaction or includes an entry to abort the in-doubt distributed transaction.
  • the persistent transaction state log 226 may indicate to commit the first distributed transaction, to abort the second distributed transaction, and lack an entry for the third distributed transaction.
  • the transaction unit 220 may not indicate to one of abort and commit to a remainder of data store units 232 included in the distributed transaction that did not store recovery information to the notice unit 210.
  • transaction unit 220 may indicate the for the first and third data store units 232-1 and 232-3 to commit the in-doubt transaction 234 for the first distributed transaction, but not send any indication to the second and fourth data store units 232-2 and 232-4, even though they are part of the same first distributed transaction.
  • the second and fourth data store units 232-2 and 232-4 do not have any in-doubt transactions 234 with respect to the first distributed transaction.
  • the at least one data store unit 232-1 may remove the recovery information 1 12 related to the in-doubt transaction 232 after one of committing and aborting the in-doubt transaction 234.
  • the data store unites 232 may be able to exercise the standard commit processing based on the aiready reconstructed prepared transaction branch. Therefore, a database consistency is maintained for this transaction spanning multiple data stores after failures.
  • system 200 is shown to include a single notice 210 unit and a single transaction unit 220, examples may include a plurality of the notice units 210, a plurality of the transaction units 220 and a set of the plurality of data store units 232-1 to 232-n. Each subset of the set of data store units 232-1 to 232-n may correspond to a different one of the plurality of notice units 210 and a different one of the plurality of transaction units 220.
  • the transaction unit 220 misses the removal of the recovery information (e.g. de-registration event) since it's asynchronous, and sends another recovery- request to that data store unit 232, there will be no in-doubt transactions at that data store unit 232.
  • that data store unit 232 may reply with a null list or similar message to the transaction unit 220. Examples are no-waited and loosely- coupled, so there does not need to be any specific synchronization or coordination between processes (e.g. the notice and transaction units 210 and 220) or on different sub-systems. This may yield better compatibility over different versions of releases, and may be easier to apply the mechanism to different environments.
  • examples may be applied to other failure cases, like to a server process hosting a data store unit 232 or a transaction unit 220 death.
  • Recovery of the data store unit 232 e.g. log splitting by the HMaster in HBase
  • a similar recovery process may be executed.
  • a transaction coordinator takeover process may be carried out via another transaction unit 220 to take over the commit responsibility from the down transaction unit 220, or with restarting the original transaction unit 220, in order to resolve the in-doubt transaction 234.
  • examples provide an efficient way to handle transactional recovery in big data environment with hundreds of data servers hosting many data shards.
  • the decentralized and asynchronous approach of examples may yield better scalability and efficiency for transactional recovery and may manage the complexity from different types of failures (logical process or physical node) while maintaining the transaction ACID properties.
  • FIG. 3 is an example block diagram of a computing device 300 including instructions for posting an in-doubt transaction to a notice unit.
  • the computing device 300 includes a processor 310 and a machine- readable storage medium 320.
  • the machine-readable storage medium 320 further includes instructions 322, 324 and 326 for posting the in-doubt transaction to the notice unit (not shown).
  • the computing device 300 may be included in or part of, for example, a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, a storage device or any other type of device capable of executing the instructions 322, 324 and 328. in certain examples, the computing device 300 may include or be connected to additional components such as memories, controllers, etc.
  • the processor 310 may be, at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one graphics processing unit (GPU), a microcontroller, special purpose logic hardware controlled by microcode or other hardware devices suitable for retrieval and execution of instructions stored in the machine-readable storage medium 320, or combinations thereof.
  • the processor 310 may fetch, decode, and execute instructions 322 and 324 and 326 to implement posting the in-doubt transaction to the notice unit.
  • the processor 310 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions 322, 324 and 326.
  • IC integrated circuit
  • the machine-readable storage medium 320 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions.
  • the machine-readable storage medium 320 may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like.
  • RAM Random Access Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • CD-ROM Compact Disc Read Only Memory
  • the machine-readable storage medium 320 can be non-transitory.
  • machine- readable storage medium 320 may be encoded with a series of executable instructions for posting the in-doubt transaction to the notice unit.
  • the instructions 322, 324 and 326 when executed by a processor (e.g., via one processing element or multiple processing elements of the processor) can cause the processor to perform processes, such as, the process of FIG. 4.
  • the first request instructions 322 may be executed by the processor 310 to send a first request to each one of a plurality of data store units that posts an in-doubt transaction to the notice unit.
  • the in-doubt transaction may indicate un-deterministic transaction at the corresponding data store unit.
  • the first request may ask to return any other in-doubt transactions at the corresponding data store unit.
  • the determine instructions 324 may be executed by the processor 310 to determine which of the data store units have in-doubt transactions that are part of a same distributed transaction to form a list of in-doubt distributed transactions, based on a response to the first request.
  • the second request instructions 326 may be executed by the processor 310 to send a second request to one of abort and commit each of the in-doubt transactions to each of the data store units that responded to the first request, based on a lookup of the in-doubt distributed transaction in a persistent transaction state log (not shown).
  • the persistent transaction state log may record distributed transactions transmitted via a two- phase commit protocol (2PC).
  • FIG. 4 is an example flowchart of a method 400 for posting an in-doubt transaction to a notice unit.
  • execution of the method 400 is described below with reference to the system 200, other suitable components for execution of the method 400 can be utilized, such as the system 100. Additionally, the components for executing the method 400 may be spread among multiple devices (e.g., a processing device in communication with input and output devices). In certain scenarios, multiple devices acting in coordination can be considered a single device to perform the method 400.
  • the method 400 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 320, and/or in the form of electronic circuitry.
  • the data store unit 232-1 identifies that it has an in-doubt transaction 234.
  • the in-doubt transaction 234 may be part of a distributed transaction that spans a plurality of data store units 230.
  • the data store unit 232-1 posts the in-doubt transaction 234 to a notice unit 210, if the in-doubt transaction 234 is not posted to the notice unit 210.
  • the data store unit 232-1 sends ail in-doubt transactions 234 to a transaction unit 220 in response to a request.
  • the transaction unit 220 may send the request in response to the in-doubt transaction 234 being posted to the notice unit 210.
  • the data store unit 232-1 one of commits and aborts the in-doubt transaction 234 in response to a command from the transaction unit 220.
  • the data store unit 232- 1 removes the in-doubt transaction 234 from the notice unit 210 after the in-doubt transaction 234 is one of committed and aborted.

Landscapes

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

Abstract

Des informations de récupération sont envoyées à une unité de notification par une unité de mémorisation de données afin d'indiquer qu'une validation d'une transaction est incertaine au niveau de l'unité de mémorisation de données. Une unité de transaction doit surveiller les informations de récupération au niveau de l'unité de notification. L'unité de transaction doit indiquer à l'unité de mémorisation de données soit de valider, soit d'annuler la transaction incertaine, si l'unité de transaction détermine que des informations de récupération associées à la transaction incertaine sont présentes au niveau de l'unité de notification.
PCT/US2015/021410 2015-03-19 2015-03-19 Envoi de transaction incertaine à une unité de notification WO2016148716A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/021410 WO2016148716A1 (fr) 2015-03-19 2015-03-19 Envoi de transaction incertaine à une unité de notification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/021410 WO2016148716A1 (fr) 2015-03-19 2015-03-19 Envoi de transaction incertaine à une unité de notification

Publications (1)

Publication Number Publication Date
WO2016148716A1 true WO2016148716A1 (fr) 2016-09-22

Family

ID=56919182

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/021410 WO2016148716A1 (fr) 2015-03-19 2015-03-19 Envoi de transaction incertaine à une unité de notification

Country Status (1)

Country Link
WO (1) WO2016148716A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0457116A2 (fr) * 1990-05-16 1991-11-21 International Business Machines Corporation Optimisation de procédures de validation
US20020124083A1 (en) * 2000-09-06 2002-09-05 Sun Microsystems, Inc. Method and apparatus for increasing the efficiency of transactions and connection sharing in an enterprise environment
US20120167098A1 (en) * 2010-12-28 2012-06-28 Juchang Lee Distributed Transaction Management Using Optimization Of Local Transactions
US20130110766A1 (en) * 2009-10-13 2013-05-02 Open Text Software Gmbh Method for performing transactions on data and a transactional database
US20130246368A1 (en) * 2012-03-16 2013-09-19 Oracle International Corporation Systems and methods for supporting inline delegation of middle-tier transaction logs to database

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0457116A2 (fr) * 1990-05-16 1991-11-21 International Business Machines Corporation Optimisation de procédures de validation
US20020124083A1 (en) * 2000-09-06 2002-09-05 Sun Microsystems, Inc. Method and apparatus for increasing the efficiency of transactions and connection sharing in an enterprise environment
US20130110766A1 (en) * 2009-10-13 2013-05-02 Open Text Software Gmbh Method for performing transactions on data and a transactional database
US20120167098A1 (en) * 2010-12-28 2012-06-28 Juchang Lee Distributed Transaction Management Using Optimization Of Local Transactions
US20130246368A1 (en) * 2012-03-16 2013-09-19 Oracle International Corporation Systems and methods for supporting inline delegation of middle-tier transaction logs to database

Similar Documents

Publication Publication Date Title
US11994959B2 (en) System and method for transaction recovery in a multitenant application server environment
Rao et al. Using paxos to build a scalable, consistent, and highly available datastore
US10289443B2 (en) System and method for sharing global transaction identifier (GTRID) in a transactional middleware environment
US9582520B1 (en) Transaction model for data stores using distributed file systems
US9880878B2 (en) Method and system for distributed task dispatch in a multi-application environment based on consensus
US11132350B2 (en) Replicable differential store data structure
Sciascia et al. Scalable deferred update replication
US9146944B2 (en) Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls
US20130117307A1 (en) Snapshot isolation support for distributed query processing in a shared disk database cluster
EP2825957A1 (fr) Systèmes et procédés d'aide à la délégation en ligne de journaux de transaction de niveau intermédiaire vers une base de données
US20150319265A1 (en) Unique identifier for a transaction
US20170139980A1 (en) Multi-version removal manager
Pankowski Consistency and availability of Data in replicated NoSQL databases
Fan et al. ALOHA-KV: high performance read-only and write-only distributed transactions
Tomic et al. MoSQL: An elastic storage engine for MySQL
Pacheco et al. Parallel deferred update replication
WO2016148716A1 (fr) Envoi de transaction incertaine à une unité de notification
Mostafa et al. Improving resource utilization, scalability, and availability in replication systems using object ownership distribution
Guo et al. Low Overhead Log Replication for Main Memory Database System
Lehner et al. Transactional data management services for the cloud
Grov et al. Scalable and fully consistent transactions in the cloud through hierarchical validation
Carvalho Generic replication of software transactional memory
Padhye et al. Scalable Transaction Management with Serializable Snapshot Isolation on HBase
Sciascia High performance deferred update replication
Mahadu et al. CloudTPS: AVAILIBILITY, SCALABILITY BASED ONLINE TRANSITION SYSTEM FOR CLOUD COMPUTING

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: 15885736

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15885736

Country of ref document: EP

Kind code of ref document: A1