Nodes of a database service may receive a read request to perform a read of a record stored by the database service and a transaction request to perform a transaction to the record. First and second indications of time may be associated with the read and transaction, respectively. A potential read anomaly (e.g., fuzzy read, read skew, etc.) may be detected based, at least in part, on a determination that the first indication of time is within a threshold value of the second indication of time. In response to detecting the potential read anomaly, the read may be performed after the transaction specified by the transaction request, regardless of whether the first indication of time is indicative of an earlier point in time than the second indication of time.

A taxonomy model in a unified data store includes a data graph structure with self-describing data objects each of which includes a unique identifier, a relationship object linking the self-describing data object to a plurality of other self-describing data objects, a domain object linking the self-describing data object to a plurality of domains, and a token object representing the self-describing data object within a domain. The model further includes an n-tuple-based multimodal data structure a content addressable memory, a tuple-reader, and a tuple evaluator configured with a set of tuple semantic rules.

Techniques are provided for identifying and deleting idle remote sessions in a distributed file system. In an example, a server that serves a plurality of server message block (SMB) sessions analyzes those sessions to determine which sessions are idle. Of the idle sessions, the server can determine which possess a lock on a computer file. Where another, active session is waiting for that resource, the server can terminate the idle session and release the lock so that the active session acquires access to the requested computer file.

Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container. Instead of validating a block of transactions using software, the hardware accelerator can validate the transactions in a fraction of the time. The peer-node software then gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block which is committed to the stored ledger.

Systems and methods to read records of a data staging table, where each record of the data staging table is associated with a package identifier, a key value of a record of a first database table, values of one or more non-key fields of the record of the first database table, and a database operation, include reading of one or more records of the data staging table, each of the read one or more records associated with a package identifier indicating the record is not being processed, and not including a same key value as any other record of the data staging table associated with a package identifier indicating the record is being processed, updating the package identifier of each of the read records of the data staging table to a first package identifier indicating that the record is being processed, creating a transaction record of a transaction queue associating the data staging table and the first package identifier, determining that the read one or more records have been processed, and, in response to the determination, deleting the one or more read rows from the data staging table and the transaction record.

Systems, methods, and non-transitory computer readable media are provided for providing a redundancy tool for performing transactions. A transaction to be performed on a data stored in a database may be received. A timestamp may be assigned to the transaction. A lock may be assigned on the timestamp. The transaction may be performed on the data. The lock may be refreshed while performing the transaction on the data. A validity of the lock may be checked at after performing the transaction on the data. Responsive to the lock being valid, a result of performing the transaction on the data may be committed.

A method of automating emulations is provided. The method comprising collecting publicly available network data over a predefined time interval, wherein the collected network data might comprise structured and unstructured data. Any unstructured data is converted into structured data. The original and converted structured data is stored in a database and compared to known network vulnerabilities. An emulated network is created according to the collected network data and the comparison of the structured data with known vulnerabilities. Virtual machines are created to run on the emulated network. Director programs and guest actor programs are run on the virtual machines, wherein the actor programs imitate real user behavior on the emulated network. The director programs deliver task commands to the guest actor programs to imitate real user behavior. The imitated behavior is presented to a user via an interface.

A computing device requests access to an application object from a remote storage system in order to locally execute application functionality without hosting application resources. An accessed object is associated with an intent in the storage system and locked. Locking an object in combination with an intent prevents computing devices that are not performing the intent from accessing the object. An intent defines one or more operations to be performed with the requested object, which are serialized as intent steps and stored in the storage system. Upon executing an intent step, the computing device stores a log entry at the storage system signifying the step's completion. A locked object remains locked until the log entries indicate every intent step as complete. Different computing devices can unlock a locked object by executing any incomplete steps of an intent associated with the locked object.

Data services are often provided with various performance guarantees. Multi-master architectures, in which multiple master servers are permitted to update a portion of the data set, may facilitate some performance requirements, but may also lead to data version conflicts in which different masters have written different versions of one or more data items. Moreover, conflicts involving different data items may have to be resolved using different conflict resolution techniques. Therefore, various data items of the data set may be associated with a conflict resolution technique selected from a conflict resolution technique set, such as manual conflict resolution; a write order policy, such as last writer wins; a conflict resolution logic; and conflict resolution based on data types. A data version conflict may be resolved by identifying and invoking the selected conflict resolution technique that is associated with the data item, and applying the conflict resolution outcome to the data item.

Example distributed storage systems, version control managers, and methods provide persistent version control for data transfers between heterogeneous data stores. A first object data store includes a versioned data object with a plurality of sequential versions corresponding to the versioned data object. A version control manager is configured to determine a creation timestamp for each of the plurality of sequential versions and store a persistent version field for each. The persistent version field remains associated with each of the plurality of sequential versions when transferred from the first object data store to a second object data store.