This month, we have a couple of maintenance releases before we release Couchbase .NET SDK 2.1.0! Version 2.1.0 will be a significant release for the SDK, especially since we will have support for the async/await keywords and a new non-blocking IO model for asynchronous operations! We were hoping to get async/await into this build, but were still integrating and testing.

Here is a sneak preview of what to expect:

In our tests we have gotten up to 10x the performance from the new async/await methods over the standard synchronous API! We’re anticipating this (2.1.0) release to be the first week of April 2015, so keep your eyes open for it.

What’s in 2.0.3?

Couchbase .NET SDK 2.0.3 is a follow up maintenance/bug fix release to 2.0.2. Honestly it’s a bit anemic giving that most of the develop efforts are focused on 2.1.0, but here are the Jira tickets:

Bug

  • [NCBC-802] – ConnectionTimeout should be SendTimeout in Configuration.*
  • [NCBC-818] – If ClientConfiguration contains password, ClusterHelper must honor it
  • [NCBC-824] – Authentication exception when opening memcached bucket with password from ClientConfiguration

Improvement

  • [NCBC-801] – Add async versions of all methods to BucketManager and ClusterManager
  • [NCBC-811] – Make operation lifespan configurable
  • [NCBC-816] – Make .NET Prepared statement API similar to Java SDK

The major feature is the addition of async methods for the ClusterManager and BucketManager classes. These were part of an awesome pull request from Weitao Lee!

What has changed?

The major changes are NCBC-802, NCBC-811, and NCBC-816. For NCBC-802, the thing to note is that the ConnectionTimeout property is now SendTimeout, because, well…that is really what it configures; the maximum amount of time that an operation can be in IO before failing – this mainly for explitly terminating the operation if the server is not responding for instance. NCBC-811 makes the timeout for an operation, that is, the total amount of time an operation can be in-flight before it either returns with a timeout or is succesful. The default is 2500ms, but this can be changed by the ClientConfiguration.DefaultOperationLifespan property.

In 2.0.2, we released support for N1QL DP4, in this release we formalized the API for Prepared Statements, making it conistent with how the Java SDK handles Prepared Statements. As of 2.0.3, the client will no longer cache a prepared statement;  the application layer should do this however since the cost of requesting a prepared statement and then using it adds little value. So, if you chose to use prepared statements, your best choice is to define a static threadsafe dictionary, like ConcurrentDictionary, and cache and reuse the prepared statement after requesting it.

How Do I Get It?

The packages are available on NuGet, S3, or you can pull the source directly from master using the tag “2.0.3” or “1.3.11”:

  • On NuGet you’ll find the packages here (2.0.3) and here (1.3.11)
  • Download the binaries here (2.0.3) and here (1.3.11)

Author

Posted by Jeff Morris, Senior Software Engineer, Couchbase

Jeff Morris is a Senior Software Engineer at Couchbase. Prior to joining Couchbase, Jeff spent six years at Source Interlink as an Enterprise Web Architect. Jeff is responsible for the development of Couchbase SDKs and how to integrate with N1QL (query language).

All Posts

One Comment

  1. Doron August 30, 2015 at 5:43 am

    I think you have a mistake in the code example: removeTasks, insertTasks & getTasks are all defined in the same way.

Leave a reply