A content management system provides a mechanism for multi-file check-in features useful for content management. The content management system provides a way for users to check in multiple files in a single action. The system allows users to either select assets (e.g., files) or drag and drop multiple assets to be checked in. The assets being checked in are automatically matched with checked out assets, and once matched, unlocked.

Techniques are disclosed relating to lock wait tracing. A computer system may operate a database that includes a lockable object. The computer may maintain a lock wait queue that stores an indication of processes waiting to acquire a lock on the lockable object. The computer system may store trace records for those processes that, upon releasing a respective lock on the lockable object when another process is waiting in the lock wait queue, have been in contention for the respective lock for over a threshold amount of time. The computer system may present ones of the trace records that identify a timeline that is usable to determine a set of processes that contributed to a delay in a process acquiring a lock on the lockable object.

Disclosed herein are system, method, and computer program product embodiments for managing a databank system. The databank system may have multiple databanks and each databank may have one or more repositories storing records (e.g., test data). The databank system exposes an application programming interface (API) and the databank system is managed by transmitting API calls to the exposed API. These API calls may be displayed to a user via GUI such that the user can copy the API call and paste the API call (or a modified version of the API call) into the code of other software application. Further, the databank system enables the owner of a databank or repository to share the databank or repository with other users accordingly to various access privileges. Further still, the databank system enables individual records to be reserved by a user, rendering the record invisible to other users until an expiration.

Improved techniques for management of access in computing environments and systems are disclosed. An object-level data access mechanism can be provided. to effectively provide an object-level locking mechanism for locking data objects of database tables, individually, as individual data objects. Furthermore, the object-level data access mechanism can be provided as a safe and efficient filtering mechanism (e.g., cuckoo filter) that effectively provide an object-level locking mechanisms for locking data objects of a database table, individually (i.e., as individual locks placed on individual data objects). For example, a set of filters (e.g., write cuckoo and read cuckoo) can be provided for a database table to facilitate concurrent database operations in a safe but efficient manner.

Techniques for processing commands may include: initially synchronizing a target database of volume reservation and registration information with a source database of volume reservation and registration information; while initially synchronizing the target database with the source database, enabling volume reservation and registration command processing on both a first node managing the source database and a second node managing the target database; while initially synchronizing the target database with the source database, performing first processing to service a first command that is any of a reservation command and a registration command for a first volume; and after initially synchronizing the target database with the source database, using the target database of the second node when servicing reservation and registration commands received at both the first node and the second node.

Techniques of implementing partition level operations with concurrent activities are disclosed. A first operation can be performed on a first partition of a table of data. The first partition can be one of a plurality of partitions of the table, where each partition has a plurality of rows. A first partition level lock can be applied to the first partition for a period in which the first operation is being performed on the first partition, thereby preventing any operation other than the first operation from being performed on the first partition during the period the first partition level lock is being applied to the first partition. A second operation can be performed on a second partition of the table at a point in time during which the first operation is being performed on the first partition.

A computing device is provided, including non-volatile memory storing a database including a table having a plurality of rows. The computing device may further include a processor configured to receive a request to perform a first transaction on a row. The processor may assign a first transaction identifier (TID) of the first transaction to the row. The processor may impose a first exclusive TID lock on the first TID of the row and may impose a first exclusive data lock associated with the first transaction on the row. The processor may perform the first transaction on the row. Performing the first transaction may include modifying the table as stored in the memory. In response to completing the first transaction, the processor may release the first exclusive data lock on the row and release the first exclusive TID lock on the first TID of the row.

A database management system for controlling prioritized transactions, comprising: a processor adapted to: receive from a client module a request to write into a database item as part of a high-priority transaction; check a lock status and an injection status of the database item; when the lock status of the database item includes a lock owned by a low-priority transaction and the injection status is not-injected status: change the injection status of the database item to injected status; copy current content of the database item to an undo buffer of the low-priority transaction; and write into a storage engine of the database item.

Test cases written to test a software application can be dynamically distributed among different sets of test cases that can be executed simultaneously in different parallel threads, thereby speeding up testing relative to executing the test cases sequentially in a single thread. To avoid database conflicts that may occur when different test cases in different parallel threads attempt to access the same database simultaneously, testing of the software application can be performed in association with a record-locking database that locks database records individually instead of locking entire database tables or locking data structures that are larger than individual records. Locking individual database records can reduce and/or eliminate the chances that a test case in one parallel thread will be unable to access a record in the database because another test case in another parallel thread is simultaneously accessing the same database.

In some examples, a computing device may store a first snapshot of a state of data in a first partition at a first point in time. The computing device may create a second partition and a third partition to each receive a portion of the data, the second partition and the third partition each including a metrics schema, and may determine information for the metrics schemas based on information in the first snapshot. During the determining of the information for the metrics schemas, the computing device may receive a write to the first partition. The computing device may update the first partition based on the write and may add a split update command to a data structure based on the write. In addition, the computing device may update at least one of the metrics schemas in the second partition or the third partition based on the split update command.