Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: A transaction engine includes a multi-version concurrency control (MVCC) module that accesses a latch-free hash table that includes respective hash table entries that include respective buckets of respective bucket items. The bucket items represent respective records, the respective bucket items each including a value indicating a temporal most recent read time of the item and a version list of descriptions that describe respective versions of the respective records, the MVCC module performing timestamp order concurrency control, using the latch-free hash table. Recovery log buffers may be used as cache storage for the transaction engine.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A first session may be established between a client and a first database server to handle a database query for the client. A request for data associated with the first session may be received by the first database server from the client, and the data retrieved. Prior to responding to the request, the data is spooled to a first session state stored in a repository made accessible by at least one computing device. The computing device(s) controls access to session states in the repository that correspond to sessions between clients and database servers. The computing device(s) enables sessions to be reestablished between the clients and database servers by accessing data of the session states in the repository and transmitting the data in response to messages received from the database servers containing session identifiers.

Abstract: Update requests that specify updates to a logical page associated with a key-value store are obtained. Updates to the logical page are posted using the obtained plurality of update requests, without accessing the logical page via a read operation.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: A transaction engine includes a multi-version concurrency control (MVCC) module that accesses a latch-free hash table that includes respective hash table entries that include respective buckets of respective bucket items. The bucket items represent respective records, the respective bucket items each including a value indicating a temporal most recent read time of the item and a version list of descriptions that describe respective versions of the respective records, the MVCC module performing timestamp order concurrency control, using the latch-free hash table. Recovery log buffers may be used as cache storage for the transaction engine.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Update requests that specify updates to a logical page associated with a key-value store are obtained. Updates to the logical page are posted using the obtained plurality of update requests, without accessing the logical page via a read operation.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Systems (and corresponding methods) that unbundle the kernel or storage engine of a database system are provided. The unbundling separates transactional aspects from storage aspects. The two components of the storage engine resulting from the unbundling are a transaction component (TC) and a data component (DC). Data storage access methods are implemented in the DC without the added complexity of dealing with transactions, which are handled separately in the TC. The interface supported by the DC is a logical interface, e.g., record oriented, in which the way that records are mapped to disk pages (or flash memory blocks, etc.) need not be exposed. The TC then deals with logical locking and logging, meaning that it need know nothing about the way pages are used in the DC.

Abstract: Systems (and corresponding methods) that unbundle the kernel or storage engine of a database system are provided. The unbundling separates transactional aspects from storage aspects. The two components of the storage engine resulting from the unbundling are a transaction component (TC) and a data component (DC). Data storage access methods are implemented in the DC without the added complexity of dealing with transactions, which are handled separately in the TC. The interface supported by the DC is a logical interface, e.g., record oriented, in which the way that records are mapped to disk pages (or flash memory blocks, etc.) need not be exposed. The TC then deals with logical locking and logging, meaning that it need know nothing about the way pages are used in the DC.

Abstract: A method of assigning transaction timestamps for use with a database that includes temporal data and may include non-temporal data. In the method, a lock is placed on a resource accessed by a first transaction to prevent conflicts with concurrently executing transactions. An access record of the lock mode and a timestamp of the first transaction is created for the resource accessed by the first transaction. The access record is accessed to determine whether a resource that a subsequent transaction accesses conflicts with the resource accessed by the first transaction. A timestamp lower bound or floor is identified for the subsequent transaction when the subsequent transaction accesses a resource that conflicts with the resource access of the first transaction. A timestamp is assigned to the subsequent transaction that is greater than the lower bound.

Abstract: A technique is described for guaranteeing recovery in a computer system comprising of recovery contracts with a plurality of obligations for a message exchange between a first component and a second component. Three forms of contract are described, governing interactions between three types of components. Each contract is bilateral, i.e. between a first component and a second component. The first and second components have mutual agreement on when the contract will be released to facilitate log truncation, and independent and/or autonomous recovery. The use of persistent and transactional components and the requirements for ensuring that it is possible to replay the components in a deterministic fashion, can result in a high cost or overhead in logging of nondeterministic events, including component interactions.

Abstract: A method of assigning transaction timestamps for use with a database that includes temporal data and may include non-temporal data. In the method, a lock is placed on a resource accessed by a first transaction to prevent conflicts with concurrently executing transactions. An access record of the lock mode and a timestamp of the first transaction is created for the resource accessed by the first transaction. The access record is accessed to determine whether a resource that a subsequent transaction accesses conflicts with the resource accessed by the first transaction. A timestamp lower bound or floor is identified for the subsequent transaction when the subsequent transaction accesses a resource that conflicts with the resource access of the first transaction. A timestamp is assigned to the subsequent transaction that is greater than the lower bound.

Abstract: A method of assigning timestamps to data items processed by a transaction. The method sets initial upper and lower limits for a transaction timestamp that will be applied to data items processed by the transaction if the transaction does not abort. The upper and lower limits are incrementally updated as data items are processed and time intervals are requested by the transaction. The lower limit is incrementally updated as data items are processed to ensure that write-write, read-write and write-read conflicts are avoided. A transaction timestamp is selected that is greater than the lower limit, but less than the upper limit.

Abstract: A technique is described for guaranteeing recovery in a computer system comprising of recovery contracts with a plurality of obligations for a message exchange between a first component and a second component. Three forms of contract are described, governing interactions between three types of components. Each contract is bilateral, i.e. between a first component and a second component. The first and second components have mutual agreement on when the contract will be released to facilitate log truncation, and independent and/or autonomous recovery. The use of persistent and transactional components and the requirements for ensuring that it is possible to replay the components in a deterministic fashion, can result in a high cost or overhead in logging of nondeterministic events, including component interactions.

Abstract: A method of assigning timestamps to data items processed by a transaction. The method sets initial upper and lower limits for a transaction timestamp that will be applied to data items processed by the transaction if the transaction does not abort. The upper and lower limits are incrementally updated as data items are processed and time intervals are requested by the transaction. The lower limit is incrementally updated as data items are processed to ensure that write-write, read-write and write-read conflicts are avoided. A transaction timestamp is selected that is greater than the lower limit, but less than the upper limit.