We have developed a Windows Mobile 6 solution that does an automatic, periodic UL synchronization on a separate thread. It works great as long as there is a decent wifi connection. When in parts of the facility where the wifi is weak, however, it starts having trouble. What appears to be happening is that the automatic sync starts but then it gets the database into a state where it seems to be waiting for the ability to update rows on the main thread.
[EDIT] The docs say: "During the upload phase, UltraLite applications can access UltraLite databases in a read-only fashion". So do update requests on a non-syncing thread wait for the upload phase to complete? Or are they supposed to immediately fail?
Anyway, one of three things usually happens from there:
The automatic sync is kind of expendable for the user...at least it's more of a nicety; if it’s doesn't happen from time to time, it really doesn’t matter. If there is a poor connection, the ideal would be to not sync at all, or at least cancel the sync after 3-5 seconds of not completing the sync. Unfortunately connection based timeout for .NET is not possible according to the docs:
ConnectionTimeout property: This feature is not supported by UltraLite.NET.
But often there may not even be a timeout occurring since the sync ultimately, usually, completes if given enough time....so maybe such a timeout wouldn’t help anyway??
The auto syncs are scheduled to occur often (like every 30 seconds), so there is very little data that ever needs to sync, and they're typically of very short duration when the wifi signal is strong (like 5 seconds maybe less)....so even if some timeout that was not based on the communication layer but on the length of the sync time itself was available, that would be nice. I don't think that's possible, but is there an option along those lines to emulate....say, for example, killing the automatic sync's thread--would that be an acceptable and safe option??
So in summary I guess these are my questions:
Sorry for the length of this post and thanks for reading this far and for any help you might impart.
Not a complete answer but...
You can certainly cancel a synchronization. In .NET, you do this by returning true from the SyncProgressed method of the sync progress listener. The sync should terminate within a second using this method.
When a wireless network goes bad, the OS will not always tell us (I suppose it's still trying to recover), and the sync stops only when UL's communication timeout expires. You can adjust the 'timeout' sync option to control how long this takes. The default is 4 minutes. I think shorter timeouts can make sense for wireless networks (but don't make it too short).
It is not generally expected that a sync in this lost-network state should block concurrent calls.