0

For the application I am working on I am forced to use an ODBC connection to access the database. One issue I'm having is that I am not sure how or even if it is possible to use this asynchronously. Does anyone know of a possible workaround if this really is impossible?

Ray Kochenderfer
  • 333
  • 1
  • 6
  • 15

1 Answers1

-1

Multtitasking and Webservers are a odd couple.

On the one hand, the Webserver does Massive Multithreading - usually 1 thread per connection - automatically. Multiple requests in paralell are pleasingly parallel.

On the other hand you should never use Multitasking on the Server side. It is expected for a page to be build from scratch, filled according to the request, processed, rendered and droped from memory ASAP. You would either keep the page in memory too long, or you never get a result before the page and everything related to it is dropped.

If there is any multitasking to be done, it has to be done on the client side. Usually using some JavaScript. Particulary AJAX. The client can then even talk to a special WebService just for this purpose (so the WebServer remains free for "real" requests.

Christopher
  • 9,634
  • 2
  • 17
  • 31
  • This is not true and the link goes to five years old document. Also doesn’t really answer anything about async or ODBC – Sami Kuhmonen Dec 19 '19 at 22:04
  • @SamiKuhmonen Has the ASP.Net pagelifecycle changed? Because I saw this same pattern in raw PHP as well. | It also answers the question by pointing out that the starting point was wrong. You do not do async in the server. You just let the client do it itself. – Christopher Dec 20 '19 at 00:39
  • You definitely *do* async in the server when needed. Async all the way is a big thing, especially here since the server can release the threads to serve other requests while waiting. Of course it requires that the task isn’t cpu bound. How would the client do an async request to the database? It can’t. – Sami Kuhmonen Dec 20 '19 at 03:06
  • " usually 1 thread per connection - automatically." - whoa. Sorry, but no. This is incorrect and is also very bad advice. One-thread-per-connection does not scale beyond a few hundred concurrent connections - all high-performance or scalable web-applications will have to use non-blocking IO. In modern applications this means using `async/await`, but before that we had to use Overlapped IO on Win32 and `epoll`/`select` on Linux - and this practice goes back _decades_. (Each thread costs at least a few hundred KB, try doing that in the late-1990s when you only had 64MB RAM to play with). – Dai Dec 18 '20 at 14:27