How to properly implement threading with CouchbaseLite

[Ragu Vijaykumar]

Hi,

I was wondering how to properly use CBL both in the main thread and background thread to the same database. Should I instantiate a CBLManager both in the main thread ([CBLManager sharedInstance]) and background thread ([[CBLManager sharedInstance] copy]) and then basically treat the two as if they were running in separate programs (each using their own CBLModels, etc.) with no sharing between the two? If I am not sharing any dynamic objects between the two, is there anything else that I need to worry about. 

Basically, I want to have a background thread load a bunch of documents into the database, and the main thread may need access to these documents during it's lifecycle. If I share the docIDs (NSStrings) between the threads, do I just make a CBLDocument with the docID and CBLModel with the CBLDocument in both threads and operate that way?

Cheers,

Ragu

[Jens Alfke]

On Apr 19, 2014, at 11:42 AM, Ragu Vijaykumar <ra...@scrxpt.com> wrote:

I was wondering how to properly use CBL both in the main thread and background thread to the same database. Should I instantiate a CBLManager both in the main thread ([CBLManager sharedInstance]) and background thread ([[CBLManager sharedInstance] copy]) and then basically treat the two as if they were running in separate programs (each using their own CBLModels, etc.) with no sharing between the two?

Exactly. Basically, those classes are not thread-safe. However, the database file itself is thread-safe.

If I share the docIDs (NSStrings) between the threads, do I just make a CBLDocument with the docID and CBLModel with the CBLDocument in both threads and operate that way?

Yes.

Also, if you listen for change notifications, they will tell you about changes made by other threads. So if you write your UI code so that the controllers are driven by change modifications and update the views accordingly, then it will Just Work.

—Jens

[Mark]

A followup question:

I can't use [CBLManager sharedInstance] because I'm calling [CBLManager initWithDirectory:options:error: ] to specify a directory.

I call this from two different objects, both on the main thread but doing separate work. One of them, however, passes a CBLModel acquired from the CBLDatabase to an NSOperation subclass to do some work on a background NSOperationQueue. I'm guessing this is going to cause me some problems.

So, questions:
1. Will using two different copies of CBLManager in two different objects on the main thread cause issues? If so, any suggestions on how to make it work?
2. Assuming that passing the CBLModel to the NSOperation is a bad idea, would the solution be to pass the docID to the NSOperation and have it call [CBLManager initWithDirectory:options:error: ] on it's own thread? Would that be safe?

Thanks!

> --
> You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/3A5867E8-B1E6-4233-B7A1-18BD00F0F46B%40couchbase.com.
> For more options, visit https://groups.google.com/d/optout.

[Jens Alfke]

On Apr 19, 2014, at 7:09 PM, Mark <mark...@gmail.com> wrote:

I can't use [CBLManager sharedInstance] because I'm calling [CBLManager initWithDirectory:options:error: ] to specify a directory.
I call this from two different objects, both on the main thread but doing separate work.

If they’re both on the main thread, they can share the same CBLManager. For instance you can store it in a global or in a property of your UI/NSApplication delegate.

One of them, however, passes a CBLModel acquired from the CBLDatabase to an NSOperation subclass to do some work on a background NSOperationQueue. I'm guessing this is going to cause me some problems.

Yeah, this gets a little harder. What I would do is create a CBLManager for use by these background operations and create a [serial] dispatch queue for it. Then you can call its objects from your operations by wrapping the calls in a dispatch_sync (or dispatch_async) block.

—Jens

[Pavel Malyshev]

On Sunday, April 20, 2014 4:49:22 AM UTC+7, Jens Alfke wrote:

Exactly. Basically, those classes are not thread-safe. However, the database file itself is thread-safe.

 So, if i want to run LiteListener while still working with database, i just need to create a separate instance of Manager and pass it to LiteListener like in couchbase-lite-android-liteserv example and everything should be fine, including simultaneous writes?

[Jens Alfke]

On Apr 21, 2014, at 4:10 AM, Pavel Malyshev <pamal...@gmail.com> wrote:

 So, if i want to run LiteListener while still working with database, i just need to create a separate instance of Manager and pass it to LiteListener

You don’t even need to do that. You can use the same instance of Manager.

Also, the thread-safety advice I’ve been giving is for iOS. I don’t know if the Java implementation has the same threading restrictions; one of the Android devs can answer that.

—Jens

[Traun Leyden]

Also, the thread-safety advice I’ve been giving is for iOS. I don’t know if the Java implementation has the same threading restrictions; one of the Android devs can answer that.

Currently couchbase lite Android isn't imposing any threading restrictions on application programmers, which from what I can tell is the "norm" (eg, ORMLite, android.database.sqlite).