A concrete example might help us understand your situation a bit better. Although I don't make asynchronous database calls, I do run quite a few queries on background threads. That doesn't require any framework modifications.
Hi Mark,
Because of the way I’m working with the business objects, for instance we have
a customer which has multiple child objects as properties which need to load
data from the database. We have thought about loading some of this data on
demand, but there will be cases where we need to load a full object all, this
is where I thought I might be about to add asynchronous data calls which would
allow me to execute multiple commands against the database.
I had previously done some work with the Background Worker in VS.net 2005 and
it worked really well, which could sit in the UI and work with the business
object and wondered if I might be able to implement this with in the Fetch Area
of the business object using _Begin & _End
Thanks, Tim.
All the processing has to be complete by the time the DataPortal Fetch method finishes executing. Once it exits, the DataPortal assumes you're done and passes the results back to the client, so any callback methods would be for naught (although it might work -by pure chance - if you're running local. I sincerely doubt if it would work via remoting). So, sample code...
private void DataPortal_Fetch(Criteria crit)
{
//Normal setup stuff for cmd1 and cmd2
IAsyncResult result1 = cmd1.BeginExecuteReader();
IAsyncResult result2 = cmd2.BeginExecuteReader();
while (!result1.IsCompleted && !result2.IsCompleted)
{
//Kill time - sleep, whatever
}
using (SqlDataReader reader = cmd1.EndExecuteReader(result1))
{
//Populate object 1
}
using (SqlDataReader reader = cmd2.EndExecuteReader(result2))
{
//Populate object 2
}
}
This should work, but I'm not sure if it's what you're truly after.
With asynchronous pages, a thread which assigned from the thread-pool to process page request, is returned to the thread pool instead of waiting for an I/O operation to complete. This means more threads available to process incoming requests, and when I/O operation is completed, another thread from the pool is guarantee to send back the response.http://blogs.microsoft.co.il/blogs/egady/archive/2008/09/29/asynchronous-asp-net-2-0-programming.aspx
The async data portal feature could, technically, be used in an ASP.NET scenario, as long as you use some sort of thread synchronization primitive to block the main "UI thread" until all the async data portal calls return.
In reality, you are probably better off using sync data portal calls, and managing your own threading outside of the data portal - in the ASP.NET environment.
The async data portal works very well in Silverlight and WPF. It works ok in Windows Forms. But in the block mode world of ASP.NET or other pure server-side settings, I think you are usually better off managing your own threads.
I say this, because the async data portal can automatically do thread marshalling in SL/WPF/WinForms thanks to Microsoft providing the underlying plumbing. But in server-side scenarios Microsoft didn't build any plumbing to do the heavy lifting, and there's no way for me to predict how someone might use threading in their application, so I can't really implement that plumbing either.
So it is, in the end, up to you to decide how to synchronize your threads on the server - which means you are better off using the sync data portal and doing all the heavy lifting in your own code.
Copyright (c) Marimer LLC