Abstract: In a distributed database, a transaction is to be committed at a first coordinator server and one or more participant servers 1210. The first coordinator server is configured to receive a notification that each participant server of the transaction is prepared at a respective prepared timestamp, the respective prepared timestamp being chosen within a time range for which the respective participant server obtained at least one lock 1220. The first coordinator server computes the commit timestamp for the transaction equal or greater than each of the prepared timestamps 1230, and restrict the commit timestamp such that a second coordinator server sharing at least one of the participant servers for one or more other transactions at a shared shard cannot select the same commit timestamp for any of the other transactions 1240. The transaction is committed at the commit timestamp 1250.

Abstract: Systems and methods are provided for sending and receiving remote procedure calls (RPCs). Based on a message in a first RPC, a second set of RPCs are created by one or more computing devices, where each of the second set of RPCs includes a portion of the message in the first RPC. The message in the first RPC is replaced with a reference to each RPC of the second set of RPCs. The one or more computing devices send the first RPC with the references, and also send the second set of RPCs.

Abstract: Systems and methods are provided for sending and receiving remote procedure calls (RPCs). Based on a message in a first RPC, a second set of RPCs are created by one or more computing devices, where each of the second set of RPCs includes a portion of the message in the first RPC. The message in the first RPC is replaced with a reference to each RPC of the second set of RPCs. The one or more computing devices send the first RPC with the references, and also send the second set of RPCs.

Abstract: In a distributed system where a client's call to commit a transaction occurs outside the transaction's lock-hold interval, computation of timestamp information for the transaction is moved to a client library, while ensuring that no conflicting reads or writes are performed between a time of the computation and acquiring all locks for the transaction. The transaction is committed in phases, with each phase being initiated by the client library. Timestamp information is added to the locks to ensure that timestamps are generated during lock-hold intervals. An increased number of network messages is thereby overlapped with a commit wait period in which a write in a distributed database is delayed in time to ensure concurrency in the database.

Abstract: In a distributed database, a transaction is to be committed at a first coordinator server and one or more participant servers 1210. The first coordinator server is configured to receive a notification that each participant server of the transaction is prepared at a respective prepared timestamp, the respective prepared timestamp being chosen within a time range for which the respective participant server obtained at least one lock 1220. The first coordinator server computes the commit timestamp for the transaction equal or greater than each of the prepared timestamps 1230, and restrict the commit timestamp such that a second coordinator server sharing at least one of the participant servers for one or more other transactions at a shared shard cannot select the same commit timestamp for any of the other transactions 1240. The transaction is committed at the commit timestamp 1250.

Abstract: Systems and methods are provided for sending and receiving remote procedure calls (RPCs). Based on a message in a first RPC, a second set of RPCs are created by one or more computing devices, where each of the second set of RPCs includes a portion of the message in the first RPC. The message in the first RPC is replaced with a reference to each RPC of the second set of RPCs. The one or more computing devices send the first RPC with the references, and also send the second set of RPCs.

Abstract: In a distributed database, a transaction is to be committed at a first coordinator server and one or more participant servers 1210. The first coordinator server is configured to receive a notification that each participant server of the transaction is prepared at a respective prepared timestamp, the respective prepared timestamp being chosen within a time range for which the respective participant server obtained at least one lock 1220. The first coordinator server computes the commit timestamp for the transaction equal or greater than each of the prepared timestamps 1230, and restrict the commit timestamp such that a second coordinator server sharing at least one of the participant servers for one or more other transactions at a shared shard cannot select the same commit timestamp for any of the other transactions 1240. The transaction is committed at the commit timestamp 1250.

Abstract: In a distributed database, a transaction is to be committed at a first coordinator server and one or more participant servers 1210. The first coordinator server is configured to receive a notification that each participant server of the transaction is prepared at a respective prepared timestamp, the respective prepared timestamp being chosen within a time range for which the respective participant server obtained at least one lock 1220. The first coordinator server computes the commit timestamp for the transaction equal or greater than each of the prepared timestamps 1230, and restrict the commit timestamp such that a second coordinator server sharing at least one of the participant servers for one or more other transactions at a shared shard cannot select the same commit timestamp for any of the other transactions 1240. The transaction is committed at the commit timestamp 1250.

Abstract: In a distributed system where a client's call to commit a transaction occurs outside the transaction's lock-hold interval, computation of timestamp information for the transaction is moved to a client library, while ensuring that no conflicting reads or writes are performed between a time of the computation and acquiring all locks for the transaction. The transaction is committed in phases, with each phase being initiated by the client library. Timestamp information is added to the locks to ensure that timestamps are generated during lock-hold intervals. An increased number of network messages is thereby overlapped with a commit wait period in which a write in a distributed database is delayed in time to ensure concurrency in the database.

Abstract: In a distributed system where a client's call to commit a transaction occurs outside the transaction's lock-hold interval, computation of timestamp information for the transaction is moved to a client library, while ensuring that no conflicting reads or writes are performed between a time of the computation and acquiring all locks for the transaction. The transaction is committed in phases, with each phase being initiated by the client library. Timestamp information is added to the locks to ensure that timestamps are generated during lock-hold intervals. An increased number of network messages is thereby overlapped with a commit wait period in which a write in a distributed database is delayed in time to ensure concurrency in the database.

Abstract: Systems and methods are provided for efficiently sending large units of data in a network. A sender computing device splits the proposal into a plurality of fragments, and sends each of the plurality of fragments to a receiver computing device. The sender computing device receives an acknowledgement from the receiver computing device for each fragment received by the receiver computing device. If no acknowledgements for any fragments are received within a predetermined time period, it may be determined that an error occurred, in which case the sender may time out or take another action. The sender computing device further sends a message to the receiver computing device, wherein a payload of the message includes one or more references corresponding to the plurality of fragments sent.

Abstract: Methods, systems and computer program products are provided for managing at least one cache for a database. In one method, an operation record is inserted in an operations log for each write operation to the database. The operation record includes a Log Sequence Number (LSN). At least one cache is updated using operation records in the operations log. To update a cache, unapplied operations in the operations log for the cache are identified using an applied LSN associated with the cache. The applied LSN denotes an LSN of a last operation applied to the cache. The unapplied operations are then applied to the cache and the applied LSN is updated with an LSN corresponding to the last unapplied operation of the unapplied operations that were applied to the cache during updating the cache.

Abstract: In a distributed system where a client's call to commit a transaction occurs outside the transaction's lock-hold interval, computation of timestamp information for the transaction is moved to a client library, while ensuring that no conflicting reads or writes are performed between a time of the computation and acquiring all locks for the transaction. The transaction is committed in phases, with each phase being initiated by the client library. Timestamp information is added to the locks to ensure that timestamps are generated during lock-hold intervals. An increased number of network messages is thereby overlapped with a commit wait period in which a write in a distributed database is delayed in time to ensure concurrency in the database.

Abstract: In a large-scale transaction such as the bulk loading of new records into an ordered, distributed database, a transaction limit such as an insert limit may be chosen, partitions on overfull storage servers may be designated to be moved to underfull storage servers, and the move assignments may be based, at least in part on the degree to which a storage server is underfull and the move and insertion costs of the partitions to be moved.

Abstract: In one embodiment, for each one of one or more content producers, access a content-producing rate at which the content producer produces one or more items of content; and for each one of one or more content consumers, access a content-consuming rate at which the content consumer consumes one or more items of content. For each one of a plurality of consumer-producer pairs, wherein the consumer-producer pair comprises one of the content consumers and one of the content producers, and the content consumer follows the content producer, select between a push strategy and a pull strategy for delivering one or more items of content from the content producer to the content consumer based on the content-consuming rate of the content consumer and the content-producing rate of the content producer.

Abstract: In one embodiment, a first one of a plurality of message processors receives a request with respect to a topic, and determines whether the first message processor itself is currently responsible for the topic. If so, then the first message processor services the request. If not, then the first message processor determines whether any of the other ones of the message processors is currently responsible for the topic. If so, then the request is redirected to another message processor to be serviced. If not, then the first message processor selects one of the message processors to be responsible for the topic and to service the request.

Abstract: In one embodiment, for each one of one or more content producers, access a content-producing rate at which the content producer produces one or more items of content; and for each one of one or more content consumers, access a content-consuming rate at which the content consumer consumes one or more items of content. For each one of a plurality of consumer-producer pairs, wherein the consumer-producer pair comprises one of the content consumers and one of the content producers, and the content consumer follows the content producer, select between a push strategy and a pull strategy for delivering one or more items of content from the content producer to the content consumer based on the content-consuming rate of the content consumer and the content-producing rate of the content producer.

Abstract: Methods and apparatus are described for partitioning native tables in a database cluster into logical tables. Each logical table is mapped into a unique portion of the native table by an intermediary server. Clients access a logical table as an ordinary, full-fledged database table through the intermediary server, which translates queries on the logical table into queries on the corresponding portion of the native table. The mapping may use the application name, logical table name, and a version number to create a native table key for each key in the logical table. A data structure storing these mappings may be stored at the intermediary server or in a native table in the database. This approach affords clients quick and flexible access to the database with better data integrity and security than native tables allow.

Abstract: In one embodiment, for each one of one or more content producers, access a content-producing rate at which the content producer produces one or more items of content; and for each one of one or more content consumers, access a content-consuming rate at which the content consumer consumes one or more items of content. For each one of a plurality of consumer-producer pairs, wherein the consumer-producer pair comprises one of the content consumers and one of the content producers, and the content consumer follows the content producer, select between a push strategy and a pull strategy for delivering one or more items of content from the content producer to the content consumer based on the content-consuming rate of the content consumer and the content-producing rate of the content producer.

Abstract: In one embodiment, a first one of a plurality of message processors receives a request with respect to a topic, and determines whether the first message processor itself is currently responsible for the topic. If so, then the first message processor services the request. If not, then the first message processor determines whether any of the other ones of the message processors is currently responsible for the topic. If so, then the request is redirected to another message processor to be serviced. If not, then the first message processor selects one of the message processors to be responsible for the topic and to service the request.