4 ms·
The example I think is compelling is JDBC. Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be me
by emccue 4y ago
The example I think is compelling is JDBC.
Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be meaningfully async without a rewrite and kotlin's coroutines can't change that.
With virtual threads that synchronous api can be used at the performance level of what a hypothetical JDBC rewite would give.
(Not that you want to hit your DB that much, but you know what I mean. You don't need to specially wrap or bundle apis to get into an async call juggle.)
- orthogonal-wren 4y agoThere are already some efforts in that direction. You can check out r2dbc and the many vert.x sql clients. While they're not really jdbc, they're fully async like you described.
- caladin 4y agoI was investigating this lately, and as you say, they are "efforts", and while laudable, I wouldn't go so far as to call them solutions. There are open issues/caveats as a result of the async model. I do think there is something great about being able to continue to leverage existing JDBC-related tooling, given that it already exists.