cancel
Showing results for 
Search instead for 
Did you mean: 

Multi-threaded Ultralite Sync

Former Member
2,536

Ultralite 12.0.1 for iOS

When I synchronize my ultralite database, i'm performing it on a background thread using the shared connection I created when the database was initialized:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
     //Synchronize with Mobilink on shared connection created when DB was initialized
     [self synchronizeWithConnection:sharedConnection]
});

According to docs:

Multi-threaded applications
Each connection and all objects created from it should be used by a single thread. If an application requires multiple threads accessing the UltraLite database, each thread requires a separate connection.

Because I am synchronizing on a different thread than my original shared connection I make when I create the database, should I create a new connection to the DB on each sync, then close the connection when sync has finished like such?

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
     //Get a new connection on the current thread
     ULConnection *newConn = [self getNewConnectionOnThisThread];
     //Sync on the new connection
     [self synchronizeWithConnection:newConn];
     //Close out the new connection
     [self closeConnection:newConn];
});

Accepted Solutions (1)

Accepted Solutions (1)

Yes, create a new connection for your synchronization. Once the database is running with your main connection, creating an additional connection is a lightweight operation.

More detail: strictly speaking, the requirement is that only a single thread access a connection at a time, including retrieval of error information. So in theory, if you could guarantee no overlap, you could pass a connection between different threads. This usually isn't worth doing. There is a limit of 14 active connections on a database -- so you can't create new threads and connections without limit 🙂 Usually this would not make sense anyway - there aren't that many processor cores - and is solved by using an operation queue or the like with limited concurrency.

Answers (0)