Ticket T683644
Visible to All Users

FAQ: XPO Async/Await Method Support

created 6 years ago (modified 5 years ago)

How do I get started with asynchronous operations in general and their XPO use in particular?

Check out the Asynchronous Programming Patterns and Task-based Asynchronous Pattern articles in Microsoft .NET Guide. To get started with XPO asynchronous APIs specifically, consider the following resources:
 - Code examples in our GitHub demos;
 - Code examples in our offline XpoTutorials demo ("c:\Users\Public\Documents\DevExpress Demos XX.X\Components\WinForms\CS\XpoTutorials\AsyncLoadingTaskBased\AsyncLoadingTaskBased.cs" );
 - Online Documentation for SessionXPQueryExtensions.

Do all ADO.NET providers support async operations and how XPO deals with it?

Not all ADO.NET providers supported by XPO support asynchronous operations. Also, even though XPO can pass System.Threading.CancellationToken from XPO async APIs to the underlying ADO.NET provider APIs, certain providers can ignore this token. To force XPO to always wrap synchronous methods in Task.Run calls, you can set the static XpoDefault.DataStoreAsyncBehavior property to WrapAlways. This can be used in desktop apps to create a non-blocking pseudo-asynchronous UI for providers like Oracle that do not natively implement async methods yet. Do not use this approach in Web apps.

Do these new Task-based APIs support cancellation?

All XPO methods accept System.Threading.CancellationToken. For more information on how to cancel async operations with XPO, refer to the attached XpoAsyncCancel.zip project (research its Form1.cs file).

Do these new Task-based APIs provide progress notifications?

We do not provide any means for reporting progress by the following reasons:
 - Standard asynchronous APIs (IDbConnection, IDbCommand, IDataReader, etc.) of ADO.NET drivers supported by XPO do not support IProgress<T> or similar means.
 - Even if we had provided XPO method overloads accepting the IProgress<T> parameters, it would not be much usable: the progress would stay at 0% most of the method execution time and then immediately go to 100%. For instance, 0%…0%…0%…0%…0%…99%…100%. That is because the most heavy operations are done at the database level and their progress could not be reliably determined.

Can I use async/await with direct SQL queries (Session methods like ExecuteScalar, ExecuteQuery, GetObjectsFromQuery, etc.)?

Yes, this is supported in v19.1+. Also, note that not all ADO.NET providers supported by XPO support asynchronous operations.
In v18.2, wrap these method calls into the Task.Run method manually, if required. Note that the asynchronous operation cannot be canceled under this approach.

Can I use async/await with XPCollection and XPView?

The XPCollection.LoadAsync method supports async/await in v.20.1+. XPView will not support async/await. We recommend that you use XPQuery<T>  instead - it is a more efficient way to query data.

Should we use the ThreadSafeDataLayer to use async/await XPO methods?

In general, the requirement to use the ThreadSafeDataLayer remains the same as if synchronous operations were used in the same context. If the existing code works with the SimpleDataLayer and you just change it to use asynchronous methods, you can continue using the SimpleDataLayer.
The only thing that should be avoided is the parallel execution of two asynchronous operations in the context of one Session instance. Use the await operator if you need to call an asynchronous method several times.

C#
await session.DoSomethingAsync(); await session.DoSomethingAsync();

What do you recommend for manipulations with large amounts of data in non-UI threads?

XPO cannot work with objects created in UI threads from non-UI threads. Data manipulations with objects in a session often occur in the same thread where the commit operation was initiated. If you process a large number of objects, these data manipulations can lock or freeze the UI. Example: you commit thousands of persistent objects using CommitChangesAsync. If this causes noticeable usability issues, you can consider the following options:

  1. Do not process thousands of objects within a session. Keep short-living sessions and save your changes in small batches.
  2. Execute data manipulations with thousands of objects in a separate thread, which creates a separate session. In this case, you can also unbind editors and the data grid from XPO objects, call the CommitChanges method in a background thread (do not use the asynchronous CommitChangesAsync method) and then rebind controls to updated data.

Does XAF's IObjectSpace support async/await?

Yes, you can perform asynchronous operations in XAF WinForms apps using the IObjectSpaceAsync interface. You can also configure asynchronous data loading in WinForms List and Detail Views with the UseAsyncLoading property. In versions older than v20.1, you can use the IObjectSpace > GetObjectsQuery<T>  method with ToListAsync, ToArrayAsync, CountAsync and other suitable IQueryable methods. You can also wrap IObjectSpace method calls into the Task.Run method manually, if required. Note that the asynchronous operation cannot be canceled with this approach.

Show previous comments (7)
Dennis Garavsky (DevExpress) 5 years ago

    Hello Klaus,
     
    You can find two examples with ToListAsync and CountAsync at https://community.devexpress.com/blogs/xpo/archive/2018/10/16/xpo-async-await-method-support-v18-2.aspx.
     
    The ExecuteAsync method is normally not called from customer code (unless you implement generic expressions or a custom LINQ provider). This is an asynchronous version of the standard IQueryProvider.Execute method. For more information, see Microsoft documentation.
     
    If you want to use this method with XPO, please describe your use-case scenario in greater detail so that we could provide you with suitable examples, or describe XPO specifics, if any.

    KP KP
    Klaus Pieper_1 5 years ago

      Hello Dennis,

      thank you. Currently ToListAsync will fit my needs.

      Dennis Garavsky (DevExpress) 5 years ago

        Great!

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.