3 months ago
- Two classic database connection models exist: Redis's single-threaded model scales connections but forbids blocking, while Postgres's per-connection process model allows blocking but doesn't scale cheaply.
- Kronotop splits connection handling from work processing: event loop threads (like Redis/Netty) manage thousands of connections without blocking, while virtual threads handle blocking I/O (e.g., FoundationDB calls, disk reads) in plain sequential code.
- The system uses two executors—virtual threads for slow operations and Netty event loops for responses—ensuring connection threads stay free, with a strict hand-off rule for replies.
- Kronotop connections hold client state, namespaces, authentication, and transactions, which are tied to the session and cleaned up on disconnection or reset, enabling easy reuse in client pools.
- The .join() method in virtual threads allows blocking calls without wasting real threads, as the runtime parks and resumes them, eliminating waiting costs.