ExecuteQueryAsync never returns

 

I thought that different managers would explain the behavior you're detecting. I don't have a ready explanation for your experience. I know that when I test for refetch it works. I'm afraid I have to ask you for evidence that it does not. And such evidence must come in the form of a small test case concerning a small number of entities in a model with data that you can send to us if need be.

 

I keep replying with examples from NorthwindIB or IdeaBladeTutorial because I know you have access to them and their semantics are well understood. If you think DevForce isn't doing something it should, your best bet is to make your point with one of these databases and a small amount of code.

 

If you can't do so, then it's important to identify why you can't. Perhaps it's an inheritance structure that isn't represented there. Fine. Try to narrow it down in your own world until you have something parsimonious enough for all of us to understand the factors involved.

 

I am not asking you to debug our product for us. I am asking that you give us a fighting chance to help you.

 

--

I really don't like the attempt to exclude refetch entities in the save. If you were saving a ton of entities and had proven that there was significant loss of performance in the refetch, you'd have a case to make. Have you actually measured the savings from this expedient? What were they? Otherwise you're adding complexity that could bite you.

 

I now think that it is biting you. If I understand your push notification code, it ignores entities that are associated with this user. That is, if you receive an entity whose EntityInfo carries this client's identity then you DO NOT PROCESS IT.

 

That means that you are not refetching when you save (because of the SaveOption) and not refetching after notification. So you are never refetching the saved entity period. And that could be a problem. Am I missing something?

 

--

 

I think your notification logic could be notably improved.

 

If I understand correctly, when the server fields a save request from a user, you compose a package of the entities that user is saving and you send that package to everyone listening. I hope you have measured the scalability of this design ... but I digress. Returning to the story.

 

Each entity in that package is wrapped in an EntityInfo that includes the identity of a client user; I'm guessing that this is the user who made the change.

 

Frankly I don't know why you include that information with each entity. If you are building a change packet per save bundle, you only need to mention the user with that bundle as a whole, not with each entity individually. You don't need EntityInfos.

 

When sending a push notification (and I don't know how you are doing this ... are you using our push mechanism?), there is no reason to notify the client of a package that has the client's identity. Why send this back?

 

If you can't help but send it (maybe you can't discriminate among receiver), the receiver can simply ignore packages with his own name on them. No reason to look at the entities inside the package.

 

--

I notice the signature of your client notification method - "private void PushNotificationCalled(object userToken, params Object[] args)" - has a "userToken" parameter. Don't know what that is but I do know that it is not used in the method itself ... so I can't tell what good it is doing. You also pass it into your SaveChanges method ... where, again, it is never used.

 

Maybe you're omitting it from your code sample ... although you include plenty of other details so I can't imagine why.

 

In any case, you don't need to send user identifying information to the server in your SaveChanges because the sender's identity is already made known to all custom methods on the server.

 

--

 

Maybe you aren't telling me everything. Fine. But you are teasing me with a boat-load of detail that is misleading me.

 

If you want to work out a comprehensive solution to your notification concern, we really should do this as a consulting engagement.

 

-- A PLEA FROM ME --

 

This is vyng for the longest Forum exchange ever.  We have strayed far from the original concern (Async never returns). We are no closer to discovering your problem with refetch (although I think it simply isn't being called in your notification method).