All I can suggest is don't use async if this is a worry.
The problem is that there's no way to cancel some of the calls that are made.
If you use a remote data portal, there's no way to cancel a remoting, WCF, asmx or ES call. You can set a timeout ahead of time with some of these technologies, but there's no way to explicitly cancel the calls.
With either a local or remote data portal, there's no way to cancel a database query. Again, you can set the query timeout ahead of time, but you can't cancel a call once it has been started.
CslaDataProvider does the async work by running the request on a background thread. Technically I could offer you a method by which you could cancel the call by aborting that thread. But that wouldn't solve your issue, because it wouldn't cancel the remote network call or the database query, and aborting threads causes other problems that are far worse and more dangerous that the one you are worried about.
In short, there's no solution (that I'm aware of) that allows safe canceling of network or database calls. So that leaves you with the option of simply not using async if this is a concern.
In local Dataportal what about using BackgroundWorker and slqcommand.cancel method. It would be posible to inplement a cancelable dataportal call?
Maybe, I don't know.
But even that wouldn't allow CSLA to do it, because any solution would need to work with both local and remote data portals, and not just SQL Server, but Oracle, web service calls or any other sort of data access people might use behind their business objects.
Remember that CSLA doesn't dictate how you get your data - that is entirely up to you - and so there's no way for CSLA to do a cancel for you.
Unfortunately, there's no way for it to even ask you to cancel - especially with a remote data portal - because there's no way for the client to send another message across the network to the already running instance of the code on the app server.
Is it possible to tell the CslaDataProvider to ignore the result of the Async call? Then it would at least appear to the user that the request was cancelled - and if they re-requested data (probably with different criteria), it wouldn't be overridden by a previous search operation.
The scenario I'm thinking of is a search screen, where the user enters search criteria. They hit search without any criteria, and then realize they have to wait too long for the data, so they want to cancel and enter more specific criteria. Even though the request is still active on the server, the user would throw away any results of that request and move on to a new request.
Copyright (c) Marimer LLC