I am attending the TechEd Europe in Barcelona and attended quite a few sessions about ASP.NET. One interesting session was about creating Async ASP.NET pages.

While the reason for creating Async pages in ASP.NET is different than that for WinForms (in ASP.NET long running tasks could exhaust ASP.NET's thread pool while WinForms its about keeping the UI responsive), it still raised a compelling case.

The point of concern is that AsyncPageTask object's BeginEventHandler has a AsyncCallBack parameter that in the code demo should be passed to a ADO.NET Command's Async version of BeginReader that also accepts a AsyncCallBack object.

When I argued that this kind of thing should be left to the DAL, the presenter responded that the AsyncCallback object should be passed to the DAL where ultimitly it would be passed to an ADO.NET async method!!

1- Does the LLBL DataAccessAdapter have an Async version counterpart to that in ADO.NET

2- If answer of (1) is NO then are missing on the Async benefits in ASP.NET or is there a workarounrd If answer of (2) is YES, the speaker also explained the even the SQL connection string needs a Async=True parameter in the config file. Does LLBL recognize and use this?

omar wrote:

I am attending the TechEd Europe in Barcelona and attended quite a few sessions about ASP.NET. One interesting session was about creating Async ASP.NET pages.

While the reason for creating Async pages in ASP.NET is different than that for WinForms (in ASP.NET long running tasks could exhaust ASP.NET's thread pool while WinForms its about keeping the UI responsive), it still raised a compelling case.

The point of concern is that AsyncPageTask object's BeginEventHandler has a AsyncCallBack parameter that in the code demo should be passed to a ADO.NET Command's Async version of BeginReader that also accepts a AsyncCallBack object.

When I argued that this kind of thing should be left to the DAL, the presenter responded that the AsyncCallback object should be passed to the DAL where ultimitly it would be passed to an ADO.NET async method!!

1- Does the LLBL DataAccessAdapter have an Async version counterpart to that in ADO.NET

No.

2- If answer of (1) is NO then are missing on the Async benefits in ASP.NET or is there a workarounrd If answer of (2) is YES, the speaker also explained the even the SQL connection string needs a Async=True parameter in the config file. Does LLBL recognize and use this?

Let's take a step back. What the demo presenter likely tried to sell was a story in which the UI was async and it was necessary because the whole code stack was tied to the page. In normal system design, if you need asynchronous behavior, you build a handshaking protocol based system (e.g. via messages, using threads), because otherwise you tie everything together to a single tier.

Example: this async stuff is really unnecessary to have in the DAL code: if you want to do async data-access, spawn a thread, let the thread do the data-access and report back to you when its done. It's an old idea but works every time. Having the DAL suddenly do async data-access is really just moving the problem around with this disadvantage that abstractions go away because layer N depends on how layer N+1/-1 works.

I.o.w.: great that they have async UI pages, but there's no reason why the underlying layers suddenly should be 'async' as well, simply because they're CONSUMED by layer N+1 (UI), so layer N is async when the UI says it is (i.e. spawns a thread and calls layer N in there).

What's next from MS, async TCP/IP Sockets?