Asynchronous Design Issue
-
Our WCF and database connections are designed to handle asynchronous calls without causing a race condition. I still use chained calls to the WCF, when loading the initial static data there can be 15-20 chained calls to load the static data. While the static data may not be critical when opening a view the sequence and completeness of the data is critical. Therefore I use chained asynch call effectively turns it into a synch process. Only when the chain is complete the view is loaded. My question is whether it would be better to send the calls asych and each callback set a flag and tries to load the view which then checks a bunch of flags to see if the data load is completed.
Never underestimate the power of human stupidity RAH
-
Our WCF and database connections are designed to handle asynchronous calls without causing a race condition. I still use chained calls to the WCF, when loading the initial static data there can be 15-20 chained calls to load the static data. While the static data may not be critical when opening a view the sequence and completeness of the data is critical. Therefore I use chained asynch call effectively turns it into a synch process. Only when the chain is complete the view is loaded. My question is whether it would be better to send the calls asych and each callback set a flag and tries to load the view which then checks a bunch of flags to see if the data load is completed.
Never underestimate the power of human stupidity RAH
I can't help but think "you're doing it wrong" if you are calling into a WCF service 15 - 20 times at start up to "load static data". Can you wrap it all into a single call? If you are using SOAP, you are sending a lot of useless crap back and forth. If you need data from calls 1,2,6 and 8 to do calls 13 - 27, you should still probably try to encapsulate it all into a single call into the WCF service to cut down on the data (speed it up). If you only have .NET clients, you can optimize it further by switching to NetTCPBinding and get rid of SOAP. If you need to support non .NET clients as well, I'd suggest REST / Json. How much data are we talking? How often does this "static" data change? If its a lot of data and it doesn't change too frequently, I'd recommend implementing a timestamp / version scheme. Instead of calling 15 - 20 times into the service, you'd do something like "I have version 1.04 of the data. Is there a newer version?" If so, then download it and cache it locally.
-
I can't help but think "you're doing it wrong" if you are calling into a WCF service 15 - 20 times at start up to "load static data". Can you wrap it all into a single call? If you are using SOAP, you are sending a lot of useless crap back and forth. If you need data from calls 1,2,6 and 8 to do calls 13 - 27, you should still probably try to encapsulate it all into a single call into the WCF service to cut down on the data (speed it up). If you only have .NET clients, you can optimize it further by switching to NetTCPBinding and get rid of SOAP. If you need to support non .NET clients as well, I'd suggest REST / Json. How much data are we talking? How often does this "static" data change? If its a lot of data and it doesn't change too frequently, I'd recommend implementing a timestamp / version scheme. Instead of calling 15 - 20 times into the service, you'd do something like "I have version 1.04 of the data. Is there a newer version?" If so, then download it and cache it locally.
Static data is tiny, usually less than 100 rows per table/call. We are only .net, oh wait they are looking at mobile stuff as well and json is useful there. I have not considered changing the binding, speed is not really an issue, I keep data small and we are all inside the firewall. I had not considered passing multiple collections or complex objects as it is not supported by basic binding (I think). I certainly would not consider the versioning, just like I don't want to deal with caching as the size and speed is not really a problem. I think I need to look into passing multiple tables and complex objects, one of the seniors devs is in my ear about doing that so I'll drop the problem on him :-D
Never underestimate the power of human stupidity RAH
-
Static data is tiny, usually less than 100 rows per table/call. We are only .net, oh wait they are looking at mobile stuff as well and json is useful there. I have not considered changing the binding, speed is not really an issue, I keep data small and we are all inside the firewall. I had not considered passing multiple collections or complex objects as it is not supported by basic binding (I think). I certainly would not consider the versioning, just like I don't want to deal with caching as the size and speed is not really a problem. I think I need to look into passing multiple tables and complex objects, one of the seniors devs is in my ear about doing that so I'll drop the problem on him :-D
Never underestimate the power of human stupidity RAH
Oh. I thought speed was your issue. I believe you can pass any serializable type. If you data is loaded by the time the view comes up, whats the issue? :).
-
Oh. I thought speed was your issue. I believe you can pass any serializable type. If you data is loaded by the time the view comes up, whats the issue? :).
SledgeHammer01 wrote:
If you data is loaded by the time the view comes up
Well the busyindicator is in heavy use but the delay is generally 1-2 seconds even on the most complex views. It was more of a philosophical question on design of the asynch/synch process. It seems ludicrous to have an asynch system and then chain the data calls. I think it is left over from when my DAL was single threaded :-O and I was getting locking issues on the data reader.
Never underestimate the power of human stupidity RAH
-
Our WCF and database connections are designed to handle asynchronous calls without causing a race condition. I still use chained calls to the WCF, when loading the initial static data there can be 15-20 chained calls to load the static data. While the static data may not be critical when opening a view the sequence and completeness of the data is critical. Therefore I use chained asynch call effectively turns it into a synch process. Only when the chain is complete the view is loaded. My question is whether it would be better to send the calls asych and each callback set a flag and tries to load the view which then checks a bunch of flags to see if the data load is completed.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
My question is whether it would be better to send the calls asych and each callback set a flag and tries to load the view which then checks a bunch of flags to see if the data load is completed.
Have each view calls its own service whenever the view is loaded. This way, you don't do 20 calls at the same time.
WP Apps - Color Search | Arctic | XKCD | Sound Meter | Speed Dial
-
Mycroft Holmes wrote:
My question is whether it would be better to send the calls asych and each callback set a flag and tries to load the view which then checks a bunch of flags to see if the data load is completed.
Have each view calls its own service whenever the view is loaded. This way, you don't do 20 calls at the same time.
WP Apps - Color Search | Arctic | XKCD | Sound Meter | Speed Dial
Wat - I am talking about 1 view and a number of static tables! Of course each view has its own VM that does the calls to the WCF!
Never underestimate the power of human stupidity RAH