3 ms·

To do so you’d step out of the JEE spec. Spring and others are trying to bridge this. Legacy DB drivers are a problem. For example, last I checked PG driver was

• cryptonector 8y ago
  So write a new driver. Yes, I know, that's a lot of work. The thread-per-client sin derives in large part from having synchronous APIs first. Every API, every project, needs an async-first approach. Even then, many many all-synchronous-all-the-time thread-per-client apps will get written, but at least it will be possible to write thread-per-CPU, async-I/O apps where those apps need to scale.
  • gpderetta 8y ago
    While I would love for every API to have an async counterpart, there is a non-trivial cost in term of complexity, latency and performance to implement an async API.
    • cryptonector 8y ago
      Cost in developer time, yes. Cost in latency and performance? No! That's the whole point of async I/O: to improve latency, performance, and scalability. It's much harder to rewrite software to use async I/O than it is to write it to use async I/O in the first place. It's also much harder to write software using async I/O than sync I/O. Therefore it's all about economics and forecasting. If you can forecast needing to scale soon enough, then start with async I/O, otherwise increase revenue and profits first then rewrite. For many companies developer time is a larger item on their budgets than the cost of extra servers and power and all that, which is why we have so much thread-per-client software -- it's a natural outcome.
      • gpderetta 8y ago
        Async operations might scale better, but the cost and latency per single operation is higher than a synchronous one.
        • cryptonector 8y ago
          Do you have a source for this?