Amazon Technologies, Inc.

Gregory J Briggs

Vincent M Rohr

A sub-container concurrency component of a tiered middleware framework ensures optimistic concurrency for transactions on hierarchical data containers. The component identifies an uppermost container level of a data read for performing a requested data modification to one or more data containers. The component further reads one or more of a parent version value or a child version value of the data container in the uppermost container level at a first time and a second time. Thus, the component writes data to the one or more data containers when each version value, such as the parent version value or the child version value, read at the first time matches its corresponding read version value read at the second time.

Sub-containment concurrency for hierarchical data containers

A multi-blob consistency component of a tiered middleware framework ensures data blobs are transacted in an atomic manner. The component determines a data blob of a data store to be modified based on an application request. The component then reads a master blob to locate a stored version number of the data blob to be modified and a version number of the master blob. A new data blob with a new version number that replaces the data blob to be modified is written to the data store. The component then reads the master blob again to re-obtain the version number of the master blob. Thus, when the obtained and re-obtained version numbers match, the component replaces the stored version number of the data blob with the new version number of the new data blob. Further, the component deletes the data blob to be modified using the stored version number.

Multi-blob consistency for atomic data transactions

A data object may be moved from a source data store to a destination data store via replication. The replication is initiated when an original data object in a source data store that is capable of being both read from and being written to is read. Following the read, the original data object is then duplicated to a destination data store. The duplicate data object is provided with a state that indicates the duplicate object is duplicated from the source data store and can be read but cannot accept a data write. Subsequently, the state of the original data object is changed to can be read but cannot be written to using optimistic locking. Further, the state of the duplicate data object is also modified to being capable of both read from and written to with the use of optimistic locking. The replication is completed with the deletion of the original data object from the source data store.

Moving data between data stores

A blob transaction component is a tiered middleware framework component that facilitates data transactions across arbitrary data blobs in an optimistically consistent manner. The component receives a request to transact data across multiple stored data blobs. For each stored data blob, the component creates a duplicate data blob. The component then creates a record blob that includes a pointer to the duplicate data blob. The stored data blob is then modified by the component to point to the record blob using optimistic locking. The component then creates a new data blob that includes modified data. The component further updates the record blob to include a pointer to the new data blob using optimistic locking. Following locking of the record blob, the stored data blob is updated with the modified data by the component, and the record blob, the duplicate data blob, and the new data blobs are deleted.

Optimistically consistent arbitrary data blob transactions

A transactionally consistent indexer is a tiered middleware framework component that updates a transactional index for a data blob according to a data transaction requested by an application. The transactionally consistent indexer determines index entries to be added or removed from a transaction index based on the application request. The transactionally consistent indexer further inserts each index entry to be added into the transaction index. With respect to each index entry to be removed, the transactionally consistent indexer uses a time stamp or version number of the index entry for ensuring optimistic concurrency during deletion. The transactionally consistent indexer then updates a data blob that is associated with each index entry to be added or each index entry to be removed based on the application request.

Transactionally consistent indexing for data blobs

A tiered middleware framework for transacting data between an application layer and a data storage layer includes modular components. The tiered middleware framework is implemented when the arrangement of the modular components enables the tiered middleware framework to meet or exceed certain data transaction criteria. However, when the data transaction criteria are not met by the tiered middleware framework with arrangement of the modular components, the modular components in the tiered middleware framework is rearranged.

Growing community of inventors

Seattle, WA, United States of America

Gregory J Briggs