How to have XPO process data on seperate thread

Attachment: DealerManager.zip (292691 bytes)

I am trying to work out how to make my GUI work better.

I currently have a project setup with remoting. Using the Blogs of Oliver, I have setup a simple winforms app that configures an access provider and setups the datastore for remoting. IT WORKS GREAT.

Using a compression sink from CodeProject made it even better.

So the app works fine, however I find that when it loads a gridview the app will stop responding for a couple of seconds while it gets the data from the remoting server. Keeping in mind that when on localhost or LAN it is lightning fast and no UI effects are felt, however when dealing with bandwidth of 10-20KBps it does take a few seconds for the data to come accross.

For testing I have been using NetLimited (which btw rocks for doing tests of low bandwidth situations)

Normally what i use to do when using WebServices is setup a new threading.thread and obtain a "dataset" on another thread and parse the dataset back to the gui thread to load into the grid, this gave the desired GUI results.

However it seems even if I create a UnitOfWork in the new thread using the remoting datalayer I setup in the GUI thread the GUI thread still hangs while the data gets processed. (ps. I have using a ThreadSafeDataLayer)

I even got a little desperate and decided to try another trick, I instanced the DataLayer in a new thread and kept that "non" UI thread running on a loop. Then in my form still create another thread (now there is 3 threads, UI thread, a UI spawned thread to create UnitOfWork and get data and the DataLayer thread), and my UI still hangs.

What is the correct process to have XPO do the data processing on another thread and pass back the result?

I note that XAF suffers this same fate.

As I am in a real time constraint here I have marked it Priority, however to assist I have do a bit of work on my end to give you a sample of my app and the remoting server, all you need to do is get something to limit your bandwidth to perform the test. also note the port is configured in compression.config (it is currently set to 8880).

Hello Michael,

Thank you for the sample project. The cause of this behavior is that the XPCollection doesn't load data until you bind it to the GridControl. To load data, call the XPCollection.Load method after creating the XPCollection. This way, you will avoid the freezing.

I'd like to warn you that the Session and persistent objects aren't thread safe, and you should be careful when loading data in the background thread. However, your implementation is quite correct and shouldn't cause any problem. I also suggest that you define the UnitOfWork as a local variable and create it in a GUI thread.

Please try this solution, and let me know whether it meets your requirements.

Thanks,
Uriah.

As per http://community.devexpress.com/forums/p/76296/273420.aspx#273420

I am back dedicated on this implementation now, the issue with the .Load in another thread is that is loads everything for that Collection except any delayed properties (which is fine as the delayed properties should only load if they are required (displayed in the grid))

The issue is when the Grid tries to show that property the application freezes while the collection runs out and collects the additional data, I can't seem to find any event to capture to know when this occurs.

I was hoping the new Async operations in v9.2 would be my answer but it seems like a very simple implementation of a multithreaded load Method and not a true Async Collection.

The reason I say this is with v9.2 I can certainly call the LoadAsync method and wait the callback and display a marqueebar on my form to show activity, this is great (however the same as just using a background thread and calling .Load) the issue again comes again with delayed properties, even though the original load was Async the additional load is within the same UI thread.

Any ideas?

I am just looking into something, I was sure that XPO had a caching mechanism whereby if you have already loaded an object and load it again it would just check to see if there was a change using the OptimisticLocking field and if not just load the one out of memory instead of going back to the datastore.

Have I got this right or am I blurring something :)

Hello Michael,

Regardless of the way in which a collection is loaded (in the same thread or asynchronously), the delayed property won't be loaded into memory until it is requested. The delayed property itself can't be loaded asynchronously on demand, because in this situation, it has already been requested from the UI thread, and the thread has to wait until data is received. We don't see any way of implementing asynchronous loading of delayed properties, so that this feature can work in any situation. I'm afraid that this problem doesn't have any general solution, and, probably, in some situations, can't be solved at all.

In my point of view, the correct way to handle this situation is to intercept the user's actions, forcing the UI to start loading the delayed property. If this property isn't yet loaded, show the "Loading" screen to the user, and access this property to initiate data loading. Once data is loaded, you can process the user's commands. Though, this approach prevents users from editing other data while the delayed is being loaded.

Thanks,
Uriah.