on 2012 Jun 11 4:56 AM
Hi Guys,
I am developing an IPad application with Ultralite DB as Client DB. App is having a functionality of Read/Write data in local DB and Sync back to server.
Requirement:- User should be able to use normal UI functionality while Sync is running.
Approach:- I am using 2 separate connection object syncConn for Synchronization and connection for normal UI read/write functionality. I am running Sync in a background thread to keep the main thread free.
Problem Description:- When Sync is running in background and i click on UI, both Sync and UI are getting hanged. I am not getting any update from Sync and UI is not going where it should go.
I checked for Concurrent Connection behavior in documentation here. It say if Local operation try to change the data which sync is trying to change it will failes the Sync. But in my case (for now) i am just trying to Read some data out of DB when clicking on UI.
Request clarification before answering.
Some info and suggestions to start...
For the connections, your approach sounds good. You need a separate connection for each different thread.
Normally UL serializes requests/calls - if you, say, execute two different statements (on two separate threads) at the same time, one call will run to completion while the other call blocks, and then the second call will run. Normally requests are short and you wouldn't notice the serialization.
For synchronization, since it's a long-running request, UL allows other requests to run concurrently. Here it is possible to notice a delay in a concurrent request because the request may have to block until the sync call is in a position to release its lock/mutex. (The sync call will continue with network I/O in the meantime, but when that's complete it will in turn block until the other request is done.)
Given all this, for UL itself, it should not be possible to hang the sync by making another request. Short delays are possible though. It may be best to perform all UL calls asynchronously to make sure the UI thread is never blocked and the app remains responsive.
For running background/asynchronous tasks on iOS, Apple suggests using NSOperations and queues. These simplify some of the common problems with threaded programming, and should lead to easier and more reliable programs. They are worth looking into if you are not using them already. The general idea would be that each database operation gets an associated NSOperation object which goes off and does the work and gathers the results - then the UI thread receives and uses the results when done.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tim, Thanks for all those suggestions. Just to update that i am already taking all these input into use. My UI related DB calls are on separate threads so as the sync call.
<Here it is possible to notice a delay in a concurrent request because the request may have to block until the sync call is in a position to release its lock/mutex.>
I completely agree with this point, but my app hasn't responded at all though i have been waiting for few minutes.
P.S. - The whole sync will take less than 40 seconds to complete.
My app is sort of form filling application for medical usage.
Yes i am constantly working on the various possible scenario which can cause it in my opinion. One weird thing i noticed last night when i run the app with breakpoints it worked just fine(Sync-UI concurrently) and when i removed them it again hangs.
In my opinion loading my apps UI is creating the problem as it load numerous views in single shot.
Meanwhile any idead would be appreciable. Will post back if i broke it.
User | Count |
---|---|
52 | |
8 | |
5 | |
5 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.