You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a tentative idea inspired heavily by what slick does. In particular, the point would be able to create an interpreter that takes two ExecutionContexts, one for the main thread pool (or whatever thread pool should be given the final results), and one ThreadPoolExecutor, that is better suited for blocking JDBC ops to give the feeling of ✨ asynchrony ✨
This idea might be self defeating in that the overhead of isolation of operations could be large enough that it's faster to leave as-is, but it's definitely worth investigating, particularly for applications such as Http servers wherein work-stealing pools can suffer greatly from hard-blockers like JDBC
The text was updated successfully, but these errors were encountered:
This is a tentative idea inspired heavily by what slick does. In particular, the point would be able to create an interpreter that takes two
ExecutionContext
s, one for the main thread pool (or whatever thread pool should be given the final results), and one ThreadPoolExecutor, that is better suited for blocking JDBC ops to give the feeling of ✨ asynchrony ✨This idea might be self defeating in that the overhead of isolation of operations could be large enough that it's faster to leave as-is, but it's definitely worth investigating, particularly for applications such as Http servers wherein work-stealing pools can suffer greatly from hard-blockers like JDBC
The text was updated successfully, but these errors were encountered: