Originally posted by mgood
... I'm wondering, though, what does your application do if the user moves on to the next question and then the previous answer fails to save? Wouldn't you want to wait before letting the user move on to make sure the answer actually saves successfully?... |
*blushes* ehm, I guess you're right about that after all...
We were on a, at first hidden, quest to defeat the fundamental nature of SL: Asynchrony. *blushes some more*.
In our attempts to have the best application responsiveness, we thought we could just cache everything and have the framework (devforce) do the async synchronization (...) for us. But even there we found out that while the records/entities were saved, they dissappeard from cache (we understand why, and it is logical!) ... so, waiting is essential and OperationResult's and IEnumerable<INotifyCompleted> are the constructs to apply.
The thought to make our own cache that is always available synchronously, will cause us issues down the line I'm sure and it is just not the type of code I want or need to write.
But there is still a thought in me that says: "Yes you can! Use two entitymanagers, one in which you read/update/create/delete, but is in disconnected state and one that actually is connected. Have a background worker periodically find all the entities not in 'Unchanged' state, import those into the connected EM, set the state to Unchanged in the disconnected EM and execute commitasync on the connected EM." ... But it is probably not specific enough to reveal issues we will find there....
So, we'll wait in the mean time ;)