Abstract: Paxos transactions are pipelined in a distributed database formed by a plurality of replica servers. A leader server is selected by consensus of the replicas, and receives a lock on leadership for an epoch. The leader gets Paxos log numbers for the current epoch, which are greater than the numbers allocated in previous epochs. The leader receives database write requests, and assigns a Paxos number to each request. The leader constructs a proposed transaction for each request, which includes the assigned Paxos number and incorporates the request. The leader transmits the proposed transactions to the replicas. Two or more write requests that access distinct objects in the database can proceed simultaneously. The leader commits a proposed transaction to the database after receiving a plurality of confirmations for the proposed transaction from the replicas. After all the Paxos numbers have been assigned, inter-epoch tasks are performed before beginning a subsequent epoch.

Abstract: Throughput is preserved in a distributed system while maintaining concurrency by pushing a commit wait period to client commit paths and to future readers. As opposed to servers performing commit waits, the servers assign timestamps, which are used to ensure that causality is preserved. When a server executes a transaction that writes data to a distributed database, the server acquires a user-level lock, and assigns the transaction a timestamp equal to a current time plus an interval corresponding to bounds of uncertainty of clocks in the distributed system. After assigning the timestamp, the server releases the user-level lock. Any client devices, before performing a read of the written data, must wait until the assigned timestamp is in the past.

Abstract: Paxos transactions are pipelined in a distributed database formed by a plurality of replica servers. A leader server is selected by consensus of the replicas, and receives a lock on leadership for an epoch. The leader gets Paxos log numbers for the current epoch, which are greater than the numbers allocated in previous epochs. The leader receives database write requests, and assigns a Paxos number to each request. The leader constructs a proposed transaction for each request, which includes the assigned Paxos number and incorporates the request. The leader transmits the proposed transactions to the replicas. Two or more write requests that access distinct objects in the database can proceed simultaneously. The leader commits a proposed transaction to the database after receiving a plurality of confirmations for the proposed transaction from the replicas. After all the Paxos numbers have been assigned, inter-epoch tasks are performed before beginning a subsequent epoch.

Abstract: Throughput is preserved in a distributed system while maintaining concurrency by pushing a commit wait period to client commit paths and to future readers. As opposed to servers performing commit waits, the servers assign timestamps, which are used to ensure that causality is preserved. When a server executes a transaction that writes data to a distributed database, the server acquires a user-level lock, and assigns the transaction a timestamp equal to a current time plus an interval corresponding to bounds of uncertainty of clocks in the distributed system. After assigning the timestamp, the server releases the user-level lock. Any client devices, before performing a read of the written data, must wait until the assigned timestamp is in the past.

Abstract: The subject matter described herein provides techniques to ensure that queries of a distributed database observe a consistent read of the database without locking or logging. In this regard, next-write timestamps uniquely identify a set of write transactions whose updates can be observed by reads. By publishing the next-write timestamps from within an extendable time lease and tracking a “safe timestamp,” the database queries can be executed without logging read operations or blocking future write transactions, and clients issuing the queries at the “safe timestamp” observe a consistent view of the database as it exists on or before that timestamp. Aspects of this disclosure also provide for extensions, done cheaply and without the need for logging, to the range of timestamps at which read transactions can be executed.

Abstract: The various embodiments described herein include methods, devices, and systems for reading and writing data from a database table. In one aspect, a method includes: (1) initiating a read transaction to read from a first non-key column of a row in the database table, the database table having a plurality of rows, each row comprising a primary key and a plurality of non-key columns, the initiating including: (a) determining that a write transaction holds a lock on a second non-key column of the row in the database table, and (b) determining that no lock is held on the first non-key column; and (2) in response, concurrently reading data from the first non-key column and writing a new column value to the second non-key column; where each non-key column includes a last-write timestamp that indicates when the last write occurred for the respective non-key column.

Abstract: The present technology proposes techniques for generating globally coherent timestamps. This technology may allow distributed systems to causally order transactions without incurring various types of communication delays inherent in explicit synchronization. By globally deploying a number of time masters that are based on various types of time references, the time masters may serve as primary time references. Through an interactive interface, the techniques may track, calculate and record data relative to each time master thus providing the distributed systems with causal timestamps.

Abstract: The various embodiments described herein include methods, devices, and systems for reading and writing data from a database table. In one aspect, a method includes: (1) initiating a read transaction to read from a first non-key column of a row in the database table, the database table having a plurality of rows, each row comprising a primary key and a plurality of non-key columns, the initiating including: (a) determining that a write transaction holds a lock on a second non-key column of the row in the database table, and (b) determining that no lock is held on the first non-key column; and (2) in response, concurrently reading data from the first non-key column and writing a new column value to the second non-key column; where each non-key column includes a last-write timestamp that indicates when the last write occurred for the respective non-key column.

Abstract: The present technology proposes techniques for ensuring globally consistent transactions. This technology may allow distributed systems to ensure the causal order of read and write transactions across different partitions of a distributed database. By assigning causally generated timestamps to the transactions based on one or more globally coherent time services, the timestamps can be used to preserve and represent the causal order of the transactions in the distributed system. In this regard, certain transactions may wait for a period of time after choosing a timestamp in order to delay the start of any second transaction that might depend on it. The wait may ensure that the effects of the first transaction are not made visible until its timestamp is guaranteed to be in the past. This may ensure that a consistent snapshot of the distributed database can be determined for any past timestamp.

Abstract: Throughput is preserved in a distributed system while maintaining concurrency by pushing a commit wait period to client commit paths and to future readers. As opposed to servers performing commit waits, the servers assign timestamps, which are used to ensure that causality is preserved. When a server executes a transaction that writes data to a distributed database, the server acquires a user-level lock, and assigns the transaction a timestamp equal to a current time plus an interval corresponding to bounds of uncertainty of clocks in the distributed system. After assigning the timestamp, the server releases the user-level lock. Any client devices, before performing a read of the written data, must wait until the assigned timestamp is in the past.

Abstract: Throughput is preserved in a distributed system while maintaining concurrency by pushing a commit wait period to client commit paths and to future readers. As opposed to servers performing commit waits, the servers assign timestamps, which are used to ensure that causality is preserved. When a server executes a transaction that writes data to a distributed database, the server acquires a user-level lock, and assigns the transaction a timestamp equal to a current time plus an interval corresponding to bounds of uncertainty of clocks in the distributed system. After assigning the timestamp, the server releases the user-level lock. Any client devices, before performing a read of the written data, must wait until the assigned timestamp is in the past.

Abstract: The various embodiments described herein include methods, devices, and systems for reading and writing data from a database table. In one aspect, a method includes: (1) initiating a read transaction to read from a first non-key column of a row in the database table, the database table having a plurality of rows, each row comprising a primary key and a plurality of non-key columns, the initiating including: (a) determining that a write transaction holds a lock on a second non-key column of the row in the database table, and (b) determining that no lock is held on the first non-key column; and (2) in response, concurrently reading data from the first non-key column and writing a new column value to the second non-key column; where each non-key column includes a last-write timestamp that indicates when the last write occurred for the respective non-key column.

Abstract: The subject matter described herein provides techniques to ensure that queries of a distributed database observe a consistent read of the database without locking or logging. In this regard, next-write timestamps uniquely identify a set of write transactions whose updates can be observed by reads. By publishing the next-write timestamps from within an extendable time lease and tracking a “safe timestamp,” the database queries can be executed without logging read operations or blocking future write transactions, and clients issuing the queries at the “safe timestamp” observe a consistent view of the database as it exists on or before that timestamp. Aspects of this disclosure also provide for extensions, done cheaply and without the need for logging, to the range of timestamps at which read transactions can be executed.

Abstract: The present technology proposes techniques for ensuring globally consistent transactions. This technology may allow distributed systems to ensure the causal order of read and write transactions across different partitions of a distributed database. By assigning causally generated timestamps to the transactions based on one or more globally coherent time services, the timestamps can be used to preserve and represent the causal order of the transactions in the distributed system. In this regard, certain transactions may wait for a period of time after choosing a timestamp in order to delay the start of any second transaction that might depend on it. The wait may ensure that the effects of the first transaction are not made visible until its timestamp is guaranteed to be in the past. This may ensure that a consistent snapshot of the distributed database can be determined for any past timestamp.

Abstract: The present technology proposes techniques for generating globally coherent timestamps. This technology may allow distributed systems to causally order transactions without incurring various types of communication delays inherent in explicit synchronization. By globally deploying a number of time masters that are based on various types of time references, the time masters may serve as primary time references. Through an interactive interface, the techniques may track, calculate and record data relative to each time master thus providing the distributed systems with causal timestamps.

Abstract: Paxos transactions are pipelined in a distributed database formed by a plurality of replica servers. A leader server is selected by consensus of the replicas, and receives a lock on leadership for an epoch. The leader gets Paxos log numbers for the current epoch, which are greater than the numbers allocated in previous epochs. The leader receives database write requests, and assigns a Paxos number to each request. The leader constructs a proposed transaction for each request, which includes the assigned Paxos number and incorporates the request. The leader transmits the proposed transactions to the replicas. Two or more write requests that access distinct objects in the database can proceed simultaneously. The leader commits a proposed transaction to the database after receiving a plurality of confirmations for the proposed transaction from the replicas. After all the Paxos numbers have been assigned, inter-epoch tasks are performed before beginning a subsequent epoch.

Abstract: Paxos transactions are pipelined in a distributed database formed by a plurality of replica servers. A leader server is selected by consensus of the replicas, and receives a lock on leadership for an epoch. The leader gets Paxos log numbers for the current epoch, which are greater than the numbers allocated in previous epochs. The leader receives database write requests, and assigns a Paxos number to each request. The leader constructs a proposed transaction for each request, which includes the assigned Paxos number and incorporates the request. The leader transmits the proposed transactions to the replicas. Two or more write requests that access distinct objects in the database can proceed simultaneously. The leader commits a proposed transaction to the database after receiving a plurality of confirmations for the proposed transaction from the replicas. After all the Paxos numbers have been assigned, inter-epoch tasks are performed before beginning a subsequent epoch.

Abstract: Throughput is preserved in a distributed system while maintaining concurrency by pushing a commit wait period to client commit paths and to future readers. As opposed to servers performing commit waits, the servers assign timestamps, which are used to ensure that causality is preserved. When a server executes a transaction that writes data to a distributed database, the server acquires a user-level lock, and assigns the transaction a timestamp equal to a current time plus an interval corresponding to bounds of uncertainty of clocks in the distributed system. After assigning the timestamp, the server releases the user-level lock. Any client devices, before performing a read of the written data, must wait until the assigned timestamp is in the past.

Abstract: Throughput is preserved in a distributed system while maintaining concurrency by pushing a commit wait period to client commit paths and to future readers. As opposed to servers performing commit waits, the servers assign timestamps, which are used to ensure that causality is preserved. When a server executes a transaction that writes data to a distributed database, the server acquires a user-level lock, and assigns the transaction a timestamp equal to a current time plus an interval corresponding to bounds of uncertainty of clocks in the distributed system. After assigning the timestamp, the server releases the user-level lock. Any client devices, before performing a read of the written data, must wait until the assigned timestamp is in the past.

Abstract: The subject matter described herein provides techniques to ensure that queries of a distributed database observe a consistent read of the database without locking or logging. In this regard, next-write timestamps uniquely identify a set of write transactions whose updates can be observed by reads. By publishing the next-write timestamps from within an extendable time lease and tracking a “safe timestamp,” the database queries can be executed without logging read operations or blocking future write transactions, and clients issuing the queries at the “safe timestamp” observe a consistent view of the database as it exists on or before that timestamp. Aspects of this disclosure also provide for extensions, done cheaply and without the need for logging, to the range of timestamps at which read transactions can be executed.