Frans,

Do you see any issue with issueing multiple fetch operations asynchronously? Would each require its own DataAccessAdapter? Can the DataAccessAdapter which implies "database connection" be shared by different threads?

Marcus

It can't be shared among threads. This is because the contained connection is a global resource inside the DataAccessAdapter and doesn't have thread schedule code around it.

Otis wrote:

It can't be shared among threads. This is because the contained connection is a global resource inside the DataAccessAdapter and doesn't have thread schedule code around it.

Okay... so in order to issue multiple simultaneous (async) fetches, I need to create a new DataAccessAdapter for each.

This acutally brings me on to another question... I'm about to implement Async fetches using my own Manager style templates (the old BeginFetch / EndFetch pattern). Is there a reason why this was never implemented in LLBLGen or was it just a feature too far ?

[Edit] BTW Async Fetches can be very usefull when combined with the new ASP.NET 2.0 Async pages... If the pages requires 5 queries, they can all be fetched Asynchronously and while the fetches are taking place, the ASP.NET worker thread is now handed back to the threadpool. Something to think about for the architecture of LLBLGen 2.0...

Marcus wrote:

Otis wrote:

It can't be shared among threads. This is because the contained connection is a global resource inside the DataAccessAdapter and doesn't have thread schedule code around it.

Okay... so in order to issue multiple simultaneous (async) fetches, I need to create a new DataAccessAdapter for each.

This acutally brings me on to another question... I'm about to implement Async fetches using my own Manager style templates (the old BeginFetch / EndFetch pattern). Is there a reason why this was never implemented in LLBLGen or was it just a feature too far ?

[Edit] BTW Async Fetches can be very usefull when combined with the new ASP.NET 2.0 Async pages... If the pages requires 5 queries, they can all be fetched Asynchronously and while the fetches are taking place, the ASP.NET worker thread is now handed back to the threadpool. Something to think about for the architecture of LLBLGen 2.0...

I'll see if I can build this in. It shouldn't be too hard actually, the main issue is: does it require thread safety to be succesful? If so, it will slow down processing due to the locks.

Otis wrote:

I'll see if I can build this in. It shouldn't be too hard actually, the main issue is: does it require thread safety to be succesful? If so, it will slow down processing due to the locks.

Not sure what you mean by thread safety being successful... I think it should never fail due to a threading bug if that's what you mean...

I always look to avoid threading issues rather than try to implement locks for them. As far as I can tell the only issue will be with the connection / transaction. Maybe the new System.Transaction namespace and the new LTM can help here by allowing the merging of multiple transactions.

I'll take a look and see what I can come up with...

Marcus wrote:

Otis wrote:

I'll see if I can build this in. It shouldn't be too hard actually, the main issue is: does it require thread safety to be succesful? If so, it will slow down processing due to the locks.

Not sure what you mean by thread safety being successful... I think it should never fail due to a threading bug if that's what you mean...

Well, the calling thread creates a dataaccessadapter, calls a method and the method returns. This can only be done if the actual fetch is done by a background thread. (IMHO). Then the call comes back, but the caller might already be gone somewhere else as the asp.net page thread is back in the threadpool. My head hurts when I even think about the consequences.

Otis wrote:

Well, the calling thread creates a dataaccessadapter, calls a method and the method returns. This can only be done if the actual fetch is done by a background thread. (IMHO). Then the call comes back, but the caller might already be gone somewhere else as the asp.net page thread is back in the threadpool. My head hurts when I even think about the consequences.

Ahhh... its not quite so tricky

My understanding of the new ASP.NET features goes something like this:

1) ASP.NET receives a request which invokes an async page (IAsyncHttpHandler behing the scenes...) 2) The page is invoked as normal and the developer has added a couple of async calls to one of the 3 new async page methods provided by the framework. For example we add 3 fetches to the async task list. 4) The framework now handles the execution of each of the async calls, you don't have to worry about it. Under the covers ASP.NET will call execute each request until it is blocked by IO and and will automatically wire the IO completion port. 5) The ASP.NET thread is now handed back to the pool 6) When all outstanding async calls have completed or timed out the framework then wires up a new ASP.NET thread to complete the page request.

So maybe there isn't a need for Begin/End methods on the Adapter for the ASP.NET example... But there might be a need for thread safety on the objects involved...

As I said... I'm going to do some work in this area and will let you know how I get on...

Marcus