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.