Abstract: Data stores that are to be configured as members of a storage group on behalf of a client are identified. The client indicates one or more types of cross-data-store operations to be performed. A transaction manager that makes acceptance decisions for write requests directed to the members based at least partly on contents of a log is instantiated, and respective write transformers are set up for at least some of the types of cross-data-store operations. During a particular time period, the workload at the storage group is monitored, and the number and types of cross-data-store operations is determined. The results of the monitoring are used to determine a billing amount for the client based on a selected pricing policy.

Abstract: At a logging service, a representation of a transaction requested by a client is received. The transaction includes at least a first write operation directed to a data object at a first data store. Based at least in part on the contents of the representation and contents of a persistent log of the logging service, a determination is made that the requested transaction is to be committed. A log record corresponding to the first write operation is inserted into the persistent log. The first write is propagated to the first data store after the record has been inserted in the persistent log.

Abstract: Resource management techniques for shared resources in a distributed system are described. Clients and servers may exchange messages according to an asynchronous messaging protocol that does not guarantee delivery or ordering of messages. A client may send a resource request message including a client timestamp and a measure of client resource demand. The server may allocate a grant of the resource to the client in a manner that prevents resource overload, and indicate the grant to the client via a message including a logical timestamp, the amount of resource granted, the client's original timestamp, and a grant expiration time. The server may acknowledge the grant and cooperatively use the resource in accordance with the grant's terms.

Abstract: A transaction request is received at a log-based transaction manager, indicating a conflict check delimiter and a read set descriptor indicative of one or more locations from which data is read during the requested transaction. Using the conflict check delimiter, a subset of transaction records stored in a particular persistent log to be examined for conflicts prior to committing the requested transaction is identified. In response to determining that none of the read locations of the requested transaction correspond to a write location indicated in the subset of transaction records, a new transaction record is stored in the particular persistent log indicating that the requested transaction has been committed.

Abstract: A sequence of configuration-delta messages from a configuration manager of a replication graph established for replicating state information of an application is received at a particular node of the graph. Representations of the messages are stored in a local configuration change repository. Using the repository, the node identifies neighbor source nodes and destination nodes of the graph. Subsequent to receiving a particular configuration-delta message indicating that a neighbor source node has been removed from the graph, a different source node is identified by the particular node, and a request is sent to the different source node to transmit a set of state transition messages pertaining to the application.

Abstract: At a logging service, a representation of a transaction requested by a client is received. The transaction includes at least a first write operation directed to a data object at a first data store. Based at least in part on the contents of the representation and contents of a persistent log of the logging service, a determination is made that the requested transaction is to be committed. A log record corresponding to the first write operation is inserted into the persistent log. The first write is propagated to the first data store after the record has been inserted in the persistent log.

Abstract: At a client-side component of a storage group, a read descriptor generated in response to a read request directed to a first data store is received. The read descriptor includes a state transition indicator corresponding to a write that has been applied at the first data store. A write descriptor indicative of a write that depends on a result of the read request is generated at the client-side component. The read descriptor and the write descriptor are included in a commit request for a candidate transaction at the client-side component, and transmitted to a transaction manager.

Abstract: A target commit sequence number (CSN) to be used to synchronize state information pertaining to an application among nodes of a state replication group (SRG) prior to a suspension of the SRG's operations is identified. Each node stores a respective commit record set of the application. Some number of SRG nodes suspend operations after synchronizing their local commit records up to the CSN. A configuration manager of the SRG verifies that, subsequent to a suspension of operations at the nodes, at least a threshold number of the nodes are available for service and have updated their commit record sets. The configuration manager then re-activates the SRG.

Abstract: At a client-side component of a storage group, a read descriptor generated in response to a read request directed to a first data store is received. The read descriptor includes a state transition indicator corresponding to a write that has been applied at the first data store. A write descriptor indicative of a write that depends on a result of the read request is generated at the client-side component. The read descriptor and the write descriptor are included in a commit request for a candidate transaction at the client-side component, and transmitted to a transaction manager.

Abstract: A first transaction manager of a partitioned storage group stores a first conditional commit record for a first write of a multi-partition transaction based on a first conflict detection operation. A second transaction manager stores a second conditional commit record for a second write of the transaction based on a second conflict detection operation. A client-side component of the storage group determines that both writes have been conditionally committed, and stores an unconditional commit record in a commit decision repository. A write applier examines the first conditional commit record and the unconditional commit record before propagating the first write to the first partition.

Abstract: Based at least in part on an optimization goal determined for a storage group comprising a plurality of data stores for which writes requests are coordinated by a log-based transaction manager, one or more lifecycle transitions are identified for data objects stored in a first data store. In accordance with a first lifecycle transition, a data object is to be transferred from the first data store to a second data store based at least in part on a duration for which the data object has been resident at the first data store. A transition agent is assigned by a configuration manager to implement the first lifecycle transition.

Abstract: A configuration manager of a storage service receives a set of service requirements, comprising one or more of: a performance requirement for one or more types of storage operations, or an access interface type requirement Based on the service requirements, a candidate storage configuration that includes one or more data store instances and a first log-based transaction manager is generated. Subsequent to an approval of the first storage configuration by a client, the establishment of the data store instances and the log-based transaction manager is initiated.

Abstract: At a client-side component of a storage group, a read descriptor generated in response to a read request directed to a first data store is received. The read descriptor includes a state transition indicator corresponding to a write that has been applied at the first data store. A write descriptor indicative of a write that depends on a result of the read request is generated at the client-side component. The read descriptor and the write descriptor are included in a commit request for a candidate transaction at the client-side component, and transmitted to a transaction manager.

Abstract: In response to a read request directed to a first data store of a storage group, a state transition indicator is identified, corresponding to a modification that has been applied at the data store before a response to the read is prepared. A read descriptor that includes the state transition indicator and read repeatability verification metadata is prepared. The metadata can be used to check whether the read request is a repeatable read. The read descriptor is transmitted to a client-side component of the storage group.

Abstract: A first transaction manager of a partitioned storage group stores a first conditional commit record for a first write of a multi-partition transaction based on a first conflict detection operation. A second transaction manager stores a second conditional commit record for a second write of the transaction based on a second conflict detection operation. A client-side component of the storage group determines that both writes have been conditionally committed, and stores an unconditional commit record in a commit decision repository. A write applier examines the first conditional commit record and the unconditional commit record before propagating the first write to the first partition.

Abstract: A distributed, web-services based storage system. A system may include a web services interface configured to receive, according to a web services protocol, a given client request for access to a given data object, the request including a key value corresponding to the object. The system may also include storage nodes configured to store replicas of the objects, where each replica is accessible via a respective unique locator value, and a keymap instance configured to store a respective keymap entry for each object. For the given object, the respective keymap entry includes the key value and each locator value corresponding to replicas of the object. A coordinator may receive the given client request from the web services interface, responsively access the keymap instance to identify locator values corresponding to the key value and, for a particular locator value, retrieve a corresponding replica from a corresponding storage node.

Abstract: At a logging service, a representation of a transaction requested by a client is received. The transaction includes at least a first write operation directed to a data object at a first data store. Based at least in part on the contents of the representation and contents of a persistent log of the logging service, a determination is made that the requested transaction is to be committed. A log record corresponding to the first write operation is inserted into the persistent log. The first write is propagated to the first data store after the record has been inserted in the persistent log.

Abstract: A sequence of configuration-delta messages from a configuration manager of a replication graph established for replicating state information of an application is received at a particular node of the graph. Representations of the messages are stored in a local configuration change repository. Using the repository, the node identifies neighbor source nodes and destination nodes of the graph. Subsequent to receiving a particular configuration-delta message indicating that a neighbor source node has been removed from the graph, a different source node is identified by the particular node, and a request is sent to the different source node to transmit a set of state transition messages pertaining to the application.

Abstract: A transaction request is received at a log-based transaction manager, indicating a logical constraint to be satisfied before the corresponding transaction is committed. The transaction manager identifies a subset of transaction records stored in a persistent change log that are to be examined to evaluate the logical constraint. Based at least in part on the result of a comparison of one or more constraint-related data signatures included in the transaction request with corresponding data signatures in the subset of transaction records, a decision is made to commit the requested transaction.

Abstract: A target commit sequence number (CSN) to be used to synchronize state information pertaining to an application among nodes of a state replication group (SRG) prior to a suspension of the SRG's operations is identified. Each node stores a respective commit record set of the application. Some number of SRG nodes suspend operations after synchronizing their local commit records up to the CSN. A configuration manager of the SRG verifies that, subsequent to a suspension of operations at the nodes, at least a threshold number of the nodes are available for service and have updated their commit record sets. The configuration manager then re-activates the SRG.