# Migrating from Developing Asynchronous Multi-Threading Programs to Reactive Programs in Java
## 3 Related Work
### Assessing R2 DBC in High-Concurrency Web Applications  
[PERSON] et al. [20] explored the impact of asynchronous frameworks and database connection pools on web application performance under high-concurrency conditions. The study utilized a configuration combining Spring WebFlux 3.3.2, R2 DBC 3.3.2, and database connection pools to handle simultaneous requests in a non-blocking manner. Tests conducted with varying loads showed that this configuration maintained an average response time of 7 ms at 500 requests, compared to 8 ms in traditional JDBC. For 50,000 requests, the asynchronous setup with a connection pool achieved 556 ms, significantly outperforming the 723 ms without a pool. Additionally, the error rate in the connection pool configuration remained at 0% for up to 150,000 requests, in contrast to the higher error rates observed in synchronous models and asynchronous models without a connection pool, which exceeded 80% under similar loads. The research emphasizes that the connection pool is crucial for realizing the full potential of asynchronous models in high-concurrency environments. By reusing connections, the connection pool minimizes the overhead of repeatedly establishing and destroyingconnections, thereby enhancing both efficiency and stability. For example, at 150,000 requests, the configuration with a connection pool achieved a throughput of 4590 requests per second, compared to 2533 requests per second for the asynchronous model without a pool and 3586 for the synchronous setup [20]. However, the study also notes that configuring the connection pool requires careful tuning, such as adjusting the maximum connection count to match workload demands. Inadequate configuration may lead to resource bottlenecks, limiting performance gains. This suggests that while the asynchronous model with connection pooling offers clear advantages, its efficacy depends heavily on proper implementation and testing [20]. The study demonstrates the advantages of the asynchronous model in high-load scenarios, offering up to 20% higher throughput and greater stability than synchronous approaches, which became ineffective under increased request loads. The results suggest that utilizing a database connection pool is essential for maximizing efficiency in database access for high-concurrency applications, highlighting the importance of non-blocking, resource-efficient setups in handling concurrent requests with minimal delays [20]. [PERSON] [21] examined the performance of R2 DBC within Spring WebFlux, comparing it with a traditional Spring MVC setup using JDBC, particularly focusing on database communication efficiency in high-concurrency environments. His study revealed that R2 DBC, integrated with WebFlux, reduced CPU and memory usage compared to JDBC in most scenarios, particularly in non-blocking environments. During the tests with 200,000 insertions, R2 DBC maintained lower CPU usage, peaking at 10%, whereas JDBC experienced notable delays and risked crashes when memory constraints were applied. R2 DBC also achieved faster response times in handling large data sets, which could be interpreted as an indicator for potential improvements in high-concurrency applications. [PERSON] [21] further identified limitations, such as challenges in handling large BLOB data with R2 DBC, as it required loading entire BLOBs into memory. This behavior implies that R2 DBC may struggle in applications where large binary objects are frequently processed, such as media storage or analytics-heavy platforms. While this limitation highlights that JDBC may remain advantageous, it also depicts the importance of aligning the database solution with the requirements of the application. Additionally, the study emphasizes that R2 DBC offers a more efficient solution \"out-of-the-box\" for standard data transactions, requiring minimal configuration adjustments, in contrast to JDBC, which may demand batch or fetch size adjustments for optimal performance [21].