node.js - Is Scala Truly Asynchronous -
these days looking scala writing non-blocking restful api. have done couple of projects in node.js , curious scala time around.
my findings till have been impossible write 100% asynchronous code in scala of underlying code blocking. can find tutorials on how use jdbc in scala application database connectivity. jdbc being blocking means application using can't work in single threaded environment queue other requests while waiting db response.play framework recommends increasing thread pool when using blocking apis means going started.
as node.js, available modules have been written asynchronously. specially of database connectors , file handlers read/write asynchronously keeping in mind nothing can block when have single thread. yet see people favoring scala on node.js type safety , computation power while being asynchronous. asynchronous behavior doesn't reflect in of tutorials , resources available online.
my question is, me failing understand or there confusion in jvm world asynchronous means?
update:
i know jdbc being synchronous not make scala synchronous have seen people argue api non-blocking yet using synchronous libraries. also, how possible write non-blocking application in scala if of drivers , libraries still blocking. if there alternatives means have careful when using library check internals see if blocking or non-blocking not case node.js.
it possible (i easy) write asynchronous applications in scala (and java) but have careful third party libraries, know of api:s blocking , asynchronous.
as example there both blocking , non-blocking io api:s provided java standard library.
jdbc common example of api inherently blocking, if want write 100% asynchronous applications have use different client database.
one big difference node.js can handle having blocking api:s asynchronous stuff. possible since have multi threading in jvm , can run blocking stuff in separate thread pool tuned task. if have 8 possible blocking database connections can run on thread pool 8 threads without blocking asynchronous code on "regular" thread pool.
as side note, have concurrency allows have 1 thread per core run asynchronous code in parallell rather 1 entire vm.
Comments
Post a Comment