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.

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 method, system, and program product for updating buffer pools in a shared disk clustered database system is provided. The method includes generating thread software code for servers of a clustered database system. Cluster-wide lock software configured with respect to a shared mode for servers of the clustered database system is received. A tablespace space reclaim function is executed for moving data pages from a first location of a shared disk structure to a second location resulting in generation of updated data page metadata. The updated data page metadata is stored within the clustered database system and functionality of thread software code is detected. The cluster-wide lock software is reclaimed, enabling remote thread software code. A second cluster-wide lock is utilized to coordinate achievement of an idle state of local and remote threads. An idle state is enabled with respect to servers of the shared disk clustered database system.

Methods and apparatuses for invoice numbering are disclosed. In one embodiment, the method comprises A method for electronically generating invoices for a party with invoice numbers where there are no gaps between invoice numbers nor duplicate invoice numbers, the method comprising: receiving, at a database, a first request to prepare an invoice for the party; preparing the invoice, including calling a command to assign an invoice number to the invoice; acquiring a limited-time lock to cause any other requests to the database related to obtaining invoice numbers for invoices for the party to wait until the invoice number has been assigned and persisting the invoice to the database has completed; assigning the invoice number for the invoice after confirming a highest invoice number already stored in the database, where the invoice number is assigned the number that is next sequentially to the highest invoice number; after assigning a number to the invoice, then persisting the invoice with the assigned invoice number to the database; and releasing the lock in response to completely persisting the invoice with the assigned invoice number to the database.

Updating multiple data records in a database system with at least one database and a first server comprises creating a first session and loading, within the first session, the multiple data records stored by the database into a memory of the first server. Update at least a first and a second of the multiple data records during the first session in the memory of the first server. A database transaction mechanism writes back the multiple data records after updating the at least first and second data records to the database which insures that either all or none of the updated database records are committed. The database transaction mechanism includes a write lock over the first and second data records stored in the database.

A node device in a blockchain receives an asset issuance transaction from an asset issuer, where the asset issuance transaction comprises a commitment value and a proof for performing a zero-knowledge proof with respect to the commitment value, and where the commitment value is calculated by inputting at least an asset type of a target asset object issued by the asset issuer to a commitment function. The zero-knowledge proof with respect to the commitment value based on the proof is initiated. It is determined that the asset type of the target asset object is in a set of legal asset types allowed to be issued by the asset issuer. In response to determining that the asset type of the target asset object is in the set of legal asset types allowed to be issued by the asset issuer, the commitment value to the blockchain is issued for storage.

A system for calendaring an event for a first user in a calendar matrix. The system comprises a hardware processor configured to authenticate a first user for accessing the calendar matrix, which comprises at least one event calendared for a second user. The hardware processor is further configured to allow the first user to enter the event for the first user into the calendar matrix. The system further comprises a memory device in communication with the hardware processor and configured to store the calendar matrix for later retrieval by the hardware processor. The hardware processor is further configured to adjust display dimensions of a rectangle representing the entered event in the calendar matrix to the first user based on projected duration of the event and independent of timeslot durations in the calendar matrix. The hardware processor is further configured to prohibit an overlap between two or more appointment events.

Techniques are described herein for managing data structure groups. Such techniques may include providing to a data structure group, by a reader, a plurality of data structure identifiers including a first data structure identifier and a second data structure identifier; mounting, by the data structure group, a first data structure identified by the first data structure identifier and including a first instance identifier; mounting, by the data structure group, a second data structure identified by the second data structure identifier and including a second instance identifier; making a first determination that the first data structure and the second data structure are mounted; making a second determination that the first instance identifier and the second instance identifier match; and marking, based on the first determination and the second determination, the data structure group as ready-to-read.

Disclosed herein are various embodiments a code simplification system. An embodiment operates by determining that a software version of a coordinator node is different from a software version of one or more worker nodes, Commits by the one or more worker nodes to a database are disabled based on the determination that the software versions differ. An update is performed on each of the one or more worker nodes. An acknowledgement that the update on each of the one or more worker nodes has completed is received, and the commits to the database by the one or more worker nodes is enabled.

Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates t the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.