# Intelligent Transaction Scheduling to Enhance Concurrency in High-Contention Workloads
## 3 Optimizing the volume of the residual set
### Dynamic Execution Phase  
#### 4.2.1 Execution Model  
Existing solutions [15; 28] employ a two-phase execution method, as shown in Figure 2b. In the first phase, conflict-free clusters are executed serially without requiring any CC protocol on \(m\) available cores \(\mathcal{C}=\{C_{1},\ldots,C_{m}\}\). We consider the situation in which each core is assigned to a single thread and use thread worker and core assignment interchangeably in the following paper. In the second phase, residual transactions involving cross-partition data items are executed using conventional CC protocols across all cores. However, this approach has inherent limitations: transactions in the residual set limit the entire transaction processing latency due to cross-partition dependencies (see Section 4.2.2 for details). The system can manage conflicts more effectively and improve concurrency control by decomposing transactions into smaller pieces based on their contention data set. **DCoS solution. ** Given the varying workloads and processing times of conflict-free clusters, particularly for residual transactions, DCoS introduces a fine-grained scheduling approach for cross-partition transactions. Firstly, transactions accessing multiple high-contention data items (i.e., cross-partition transactions) are decomposed into transactions pieces leveraging runtime pipelining (RP) [9]. RP organizes these pieces based on data dependencies and assigns each group a rank. Depends on whether access hot data item in different partition, the transaction pieces can be further divided into _contention-intensive transaction pieces_ and _non-contentious transaction pieces_. Among the same group, existing RP-based methods mainly merge these accesses into a single execution unit to avoid deadlocks, which limits the level of parallelism that can be potentially exploited. We employ fine-grained scheduling with a DRL-based executor to explore more concurrency among the same group (see Section 4.2.3 for details). Then DCoS employs an _adaptive two-level queue execution model_ as shown in Figure 2a. * **Hot queue:** Designed to handle contention-intensive transaction pieces requiring fine-grained scheduling at the operation level. A DRL-based executor is employed to maximize concurrency within these contention-intensive transaction pieces. * **Cold queue:** Designed to handle transactions (or transaction pieces) that do not involve cross-partition data. Utilize a coarse-grained scheduling approach (e.g., conventional methods such as round-robin allocation), where entire transactions (pieces) are assigned to threads. The adaptive two-level queue execution model adheres to the following scheduling principles:  
_Principle 1: Concurrent execution and scheduling._ DCoS executes cold-queue transactions with hot-queue transactions scheduling concurrently. The fine-grained scheduling process dynamically adapts to execution progress according to thread state. _Principle 2: Priority-based scheduling._ Transactions in the hot queue are assigned higher execution priority, while cold-queue transactions are assigned lower priority. If no hot transactions can proceed due to dependency constraints, the thread first fetches from the cold queue. Instead of forcing hot-queue transactions to wait idly, the system dynamically schedules transactions in the cold queue to execute first. _Principle 3: Dependent enforcing._ Hot-queue transactions are often dependent on cold-queue transactions. Since cold-queue transactions access low-contention data but may still hold locks on critical data items, hot-queue transactions that require those items must wait until the locks are released. In addition, execution dependencies between transaction pieces within the same transaction are enforced via the lock mechanism defined in the RP framework [9]. Specifically, a later transaction piece cannot acquire the locks until all earlier pieces have released theirs.