Blocking I/O makes the calling execution path wait until an input or output operation completes or fails. Database calls are essentially RPCs, and standard drivers such as JDBC commonly use blocking I/O. Combining these waits with application threads, memory locks, RPC behavior, and database locks creates an interwoven programming model whose performance and failure behavior are difficult to predict. section 1.4.1 section 1.3
Blocking I/O becomes a practical scaling concern when:
- Controllers can freely combine database operations such as finding conversations and inserting messages, producing unpredictable access flows. section 1.4.1
- Synchronous RPC and blocking I/O are used to scale across a network, while the contrasting approach uses asynchronous messaging and nonblocking I/O. section 1.3
- Thread locks and database locks must be coordinated separately because they protect different resources. section 1.4.1
Database-backed team chat
A team-chat controller might combine calls such as findConversations and insertMessage. Because these database operations behave like blocking RPCs, different controllers can create many access flows, increasing the risk of deadlocks and other performance problems as the application scales. section 1.4.1
Trace how DAO calls can be combined into different database access flows, making the coordination costs of blocking operations visible. section 1.4.1
