Hello, the Kotlin community! I have a question abo...

# server

[Alex Sinclair]

Hello, the Kotlin community! I have a question about Tomcat and Coroutines - specifically: is there benefits to be had?

We made the switch to Kotlin over a year ago, and we've now Kotlin got about 11k lines of Kotlin, and only another 47k lines of Java to convert! I've loved learning the language, it's a real delight - but I've got a way to go yet, and I'd like to know more.

So, is there a point to using Coroutines when Tomcat apparently spins up a thread per request? That is, if we go request->logic->db->logic->response, we could make that ->db-> call asynchronous using coroutines, but... is there a benefit? In JS the async/await makes sense because of the single-threading and how it nicely replaces callbacks, but... if Tomcat pauses the thread (which I assume it does, I'm certainly no expert on anything I've said here) then coroutines wouldn't have much benefit, right?

I appreciate any insights you have, including schooling me on my false assumptions and faulty reasonings 🤣

[Joe]

If you use Servlet API 3.0's AsyncContext you can get the tomcat thread to be released and then execution can happen in your coroutine dispatcher. bridging your db implementation to be async may be another thing as jdbc is synchronous, but if you're using an async non-jdbc impl could be good (we use jooq and bridge to a Flow using this code: https://github.com/trib3/leakycauldron/blob/main/db/src/main/kotlin/com/trib3/db/jooqext/ResultQueryFlow.kt ; somehting similar could be done for a non-jooq jdbc based API). in a solution like this, you're still using a thread per db query, but the benefits of coroutines still show up in having synchronous-looking async code. queries become somewhat easier to cancel, for example.

[asad.awadia]

Using coroutines does not make your code magically async. Remember coroutines are just syntactic sugar over callbacks/future/async style APIs

[Joris PZ]

If your current thread-per-request design is running well, then I don't think there would be much point in making your database calls asynchronous. Unless you are running into problems with not having sufficient threads available to handle your current concurrent load, you would be introducing complexity without any discernible benefit.

But, if you are routinely running out of threads, or have to run multiple Tomcat instances behind a load-balancer to deal with concurrent load, and the bottleneck in throughput is your database, then it might be worthwhile to investigate asynchronous alternatives. But you would probably want to switch to asynchronous database drivers to really solve anything, and that would mean replacing stuff like Hibernate with non-blocking alternatives like Spring Data R2DBC.

[Alex Sinclair]

Thanks everyone! It's good to know that there's plenty of use cases for it, I just haven't come across any yet. I'll keep this in mind for future developments - I can't work on Tomcat forever eh? 🤣
I really appreciate you all taking the time to explain this, thank you very much