Gocb v2 Collection threadsafe?

Go SDK
1

Hi All,

I’m just getting started integrating with couchbase, using golang. It seems like v2 is the best place to start (even though it is still a prerelease).

It seems like Collections are the v2 way to interact with buckets. My question is: Are Collections threadsafe? i.e. can I put a pointer to a collection into a grpc or http handler and just use the same collection to do all of my querying for all of my concurrent requests, or should I give the handler the pointer to the bucket and instantiate the DefaultCollection() for each request?

Thanks! :slight_smile:

2

Actually… I’m not so sure about v2 anymore. You do not actually get any errors when you connect to a non-existent database, you only get errors when you try to execute a query. That’s a little too late in my opinion…
The following code:

auth := gocb.PasswordAuthenticator{
	Username: "Administrator",
	Password: "password",
}
opts := gocb.ClusterOptions{
	Authenticator: auth,
}
cluster, err := gocb.NewCluster("blahblah", opts)
if err != nil {
    return err
}
bucket := cluster.Bucket("non-existent", nil)

doesn’t return an error. That’s kind of weird IMO.

3

Hi @mec07, you’re correct that collections are how to interact with KV operations. Services like query are part of the cluster level API (although you still need to open a bucket before you can query at the moment, this should be changing before GA though). Collections indeed should be threadsafe, if you open multiple instances of the default collection on a single bucket then they’ll share the same connection behind the scenes anyway.

Actually… I’m not so sure about v2 anymore. You do not actually get any errors when you connect to a non-existent database, you only get errors when you try to execute a query. That’s a little too late in my opinion…

You’re absolutely correct that this is how it works now. We defer any connection errors until the first operation - be it KV, query etc… Thanks for this feedback, it’s really valuable to us at this stage.

4

I just thought that I’d expand a little on why we are currently deferring connection errors to first operation. The thinking behind doing that is that any errors that can occur during connecting can also occur later (after you think you’re already connected) and so it makes sense to not require users to have to check for those errors in two separate locations.

Also, we have a feature coming that will allow gocb.NewCluster (this is going to be renamed to Connect) to perform the initial connection and return errors that occur. Although, this won’t cover a non-existent bucket as we can’t know that until you open the bucket :slight_smile:.

5

Thanks @chvck, making gocb.NewCluster perform the initial connection would be very helpful. I want to know at server spin up time that there is an issue with connecting to the database, rather than when the first request gets made to it. The non-existent bucket is a red-herring, don’t worry about that.

6

As well as that functionality we are also planning on adding functionality to allow you do health checks that you could use once you’ve opened a bucket to ensure that the bucket has been opened successfully. This gives the option of checking on the state of the bucket before performing operations or just handling any issue at time of the first operation.

7

That sounds great. If you could post on here when v2 has become stable, it would be much appreciated :slight_smile: Thanks @chvk!