Hi guys, some guidance if you can, I have posted this question on the Support Center

www.devexpress.com/issue=Q205441

The basic situation is I have a server app that exposes an IDataStore over .NET Remoting, and a client accessing the XPO datastore across the wire.

This works quite well including a Compression sink I picked up on CodeProject.

The issue I have is that I am dealing with connections that are usually 10KBps to 20KBps, so when you have a bit of data it can take up to a couple of seconds for the data to come over the wire (my tests show around 10-50KB of data) although that isn't much the GUI still hangs while the data is being obtained.

I use to have a Typed Dataset for my BO and do this over a WebService, I would send a simple request and the WebService would return a Dataset, this could be done easily in a seperate thread and pass back the result dataset to the UI to update the datasource of the grid. The thing I don't like is datasets are bloaty and annoying to work with.

I have wanted to move over the XPO but had a legacy database system. I have been playing for a while now and worked out that XPO is awesome, regardless of the legacy database I can still connect to it and manipulate it "perfectly" :)

Now the issue is getting the interface to work the same :(

I note that XAF also suffers this fate, whereby when data is being obtained the UI thread locks up until complete.

So my question is this, where do you perform the code such as

dim uow as new UnitOfWork(program.Data, nothing)
dim theData as new XPCollection(of MyDataType)(uow)
myGrid.datasource = theData

to run on another thread?

Please don't hesitate to download the sample app I have dummied up for DX and have a play, I would welcome any suggestions. Oliver's blogs were good however I would say they are incomplete. It is a complete sample of exposing a IDatastore using .NET Remoting and also has a compression library I got from CodeProject. Might be handy for some of you, I know I woulda loved to have a head start :)

Thanks guys and hope to here from you soon.

Another scenario that this is required (am about to run into it now ) is attachments (ie. Objects with Bytes.

This can take considerable time, any ideas how to get this to process on another thread? and out of interest any way to monitor the .NET Remoting transport to know how the transfer is going?

Hey Michael, try loading your collection just after creating it and before adding it to the datasource.  For example:

Dim locations As New XPCollection(Of tblLocations)(uow)
locations.Load()

This should take care of the app hanging.

-Chris

 How did you go with this michael??

Hey Chris,

I had to move forward with the project as a deadline was looming, so I left it with the "freezing" feature, the customer understood it was a "temporary" feature, will be getting back onto multi-threading the data in the next day or so, will post a new sample when I implement it.

Basically I will remove the datasource binding from the designer and have a thread spawn from the load of the form that will start a marquee bar and the "xpcollection.load" then invoke a method that will assign the xpcollection to the xtragrid and stop the marquee

The only thing I haven't quite worked out yet is how much trouble I might get into with "saving" records, I don't want to "unbind" the XtraGrid to perform the tasks, I would need someway to "lock" the xtragrid so that people can't "use" the grid while an update is occuring, the only thing I forsee here is that when if XPO does do an update during that other thread the xtragrid probably won't be notified of a datasource change, so I am thinking I may have to call the RefreshDatasource after I "reenable" the grid.

Should be great fun, multithreading something that isn't thread safe, lots of strange bugs coming up :)

Hey Trevor,

Thanks for your reply, my application at this stage is an SDI (will be moving towards an MDI as I get to transfer more of the legacy systems into it). The main reason I want to use mutli-threading is that I am using .NET remoting so operations can take up to 10-20 seconds depending on the table, and during that time the application stops receving window messages and appears unreponsive. What I use to do with my WebService is have it go and collect a dataset on another thread and pass the dataset back, during this time I have a marquee edit running on a status bar.

I am trying to accomplish something similiar. The concurrency with multi user I am handling with optimistic locking and that isn't an issue. I am mainly trying to accomplish a responsive application.

The issue I forsee is that the XPCollection and isn't thread safe, so if I have the XPCollection as a public variable which I manipulate from another thread I am concerned what will occur with the bound datagrid.

Some heavy testing is required :)

Any thoughts?

"Michael Proctor" wrote in message news:261815@community.devexpress.com...

Hey Trevor,

Thanks for your reply, my application at this stage is an SDI (will be moving towards an MDI as I get to transfer more of the legacy systems into it). The main reason I want to use mutli-threading is that I am using ..NET remoting so operations can take up to 10-20 seconds depending on the table, and during that time the application stops receving window messages and appears unreponsive. What I use to do with my WebService is have it go and collect a dataset on another thread and pass the dataset back, during this time I have a marquee edit running on a status bar.

I am trying to accomplish something similiar. The concurrency with multi user I am handling with optimistic locking and that isn't an issue. I am mainly trying to accomplish a responsive application.

The issue I forsee is that the XPCollection and isn't thread safe, so if I have the XPCollection as a public variable which I manipulate from another thread I am concerned what will occur with the bound datagrid.

 

Some heavy testing is required :)

Any thoughts?

---

http://community.devexpress.com/forums/p/76296/261815.aspx#261815

Hi Trevor,

Trevor Westerdahl:

What I mean is that the form performing the request should not let the user do anything while the action is performed on another thread. *If it is a single document interface, then there are no advantages to multi-threading*.

Actually it makes sense even on single doc applications. Background operation would leave UI responsive, you can add a Cancel button, put up statistics to distract user, etc. and/or let user do other unrelated operations.

"Miha Markic" wrote in message news:261946@community.devexpress.com...

Hi Trevor,

Trevor Westerdahl:

What I mean is that the form performing the request should not let the user do anything while the action is performed on another thread. *If it is a single document interface, then there are no advantages to multi-threading*.

Actually it makes sense even on single doc applications. Background operation would leave UI responsive, you can add a Cancel button, put up statistics to distract user, etc. and/or let user do other unrelated operations.

---

Miha Markic [MVP C#, INETA Country Leader, DXSquad]
Blog:cs.rthand.com/blogs/blog_with_righthand
Righthand .net consulting and software development

---

http://community.devexpress.com/forums/p/76296/261946.aspx#261946

LOL was still having problems getting a multithreaded XPO .NET Remoting solution working so I did a search (search.devexpress.com) and come across this thread. it is my own thread

Well I am back on the case with an MDI app running, the issue still remains that the UI locks while XPO goes and collects data.

The issue I have found is even if I do a background thread and do a XPCollection.Load the issue is Delayed properties such as associated collections and records, when these come into view the XPCollection then goes out to collect more information to display the string in the field.

I found that I can hook into the Session.ObjectLoading and Session.ObjectLoaded event and I have been trying to pop up a little Loading Form on another thread in front of the main form. It hasn't worked to well as a form from another thread can't modal another form and when you disable the main form while the grid is in the process of waiting for XPO to return the values the grid gets a bit Red X on it :(

I was hoping with v9.2 and the announcement of LoadAsync that we could now support this much easier, however it appears that there is no "UseAsync" type option and the Async method is a manual call, this doesn't help when the XPCollection requires more data from DelayedLoaded properties as the Session will do a standard Load on this value.

Personally I think the Session or DataLayer needs a "LoadingFromDataStore" "LoadedFromDataStore" type event, therefore if it is found in the Cache then there isn't an issue however if it has to query the datastore then fire this event and also have a property such as UseAsync so that it can fire another thread to go off and perform the data request and callback once it is received.

This would also solve any exceptions that might occur while XPO is retreiving data, at the moment when XPO has an issue while a Grid is trying to display properties the Grid goes to a Red X. We need a better way to hook into what XPO is doing so we can notify users of actions and also handle any communication issues that might occur.

Has anyone come across this and have a way around it?

Thanks guys and hopefully we can have Oliver or Gary make a comment on this.

Cheers TIA

 I have an XPO Database in production and the client has asked for an autosave option. Even with an SDI the timer used for autosave will always operate on its own thread. So far I have found this request more trouble than it is worth. I have convinced the client he doesn't want it right now; but I am sure it is going to rear its ugly head again.

Why is multithreading a problem with XPObjects

This was my support center question on it, I have reactivated it with these questions.

www.devexpress.com/issue=Q205441

Also as a side note for the transfer of attachments to my database I used a FTP component to allow me to transfer files to and from the server which gave me good control over status of transfer as well as resuming features.

Your support center issue is marked as private, so we can't view it.

 Hi Brendon, 

Brendon Muck [DX Squad]:

Your support center issue is marked as private, so we can't view it.

no, Michael posted (inadvertently, I think) the "Edit"-Link. Edit is private.

Here is the "View"-Link: http://www.devexpress.com/Support/Center/p/Q205441.aspx

HTH, Ralph