Multi-document ACID transactions without Java


This is in relation to CB server 6.5.

Is it possible to use N1QL to run multi-document ACID transactions, or is there an API that will be available to run them without using the SDK 3.0 / Java?


N1QL doesn’t support transactions. You must use Java SDK with KV api directly.

Hi Eugaia,
Would you be able to provide some details on your use case and application stack? That might help in providing a possible solution to you.


@vsr1 When you say the KV API, is that an extension to the Memcache protocol? Is there documentation for that? I looked in the Data Service documentation section, but couldn’t find it.

@shivani_g Basically I’d like to create an in-house SDK for Nginx/Lua that works with multi-document transactions. It’s not possible to give you one specific use case.

If there’s documentation for the KV service, I expect that I could figure out the rest for Ningx/Lua - but I can’t seem to find the info anywhere.


Each SDK have there own API’s directly interact with KV( Data Service). You should check SDKs API’s.

Thanks for the clarification.
Part of the transaction logic is in the SDK client, so you cannot use transactions directly from the KV APIs.


Thanks for that.

Is there documentation specifically about the KV API, so that we can create our own SDK?

Alternatively, is the C-language SDK going to be available in 3.0 with the GA of 6.5? If that’s working smoothly, we could build our Nginx/Lua (OpenResty) SDK on top of that.


Thanks for your response.

As mentioned, we’re creating our own SDK for Nginx/Lua, not using an existing SDK.

We may be able to use the C SDK to embed it in Nginx, but was looking for a way to avoid doing that if possible.


Yes, there will be a C/C++ SDK that you can use to build your Nginx/Lua SDK. It may be a little bit later than the GA of 6.5.

Thanks. I’ll keep an eye out for it.

Note that while it’s a bit dated, there is an nginx module for Couchbase that uses the C SDK. It would probably need quite a bit of updating, but might form a good base for you:

Pull requests gladly accepted. :slight_smile:

Thanks for this info.

I had a quick look at the code of the module. I’ve written Nginx modules before, so am familiar with the format.

Sadly, this type of module would be unsuitable for our needs, because although it could be adapted to update the module to the newer SDK, the resulting setup would add unnecessary overhead when using Nginx/Lua. For an equivalent amount of effort, an optimal module could be be developed.

Ideally, we’d actually want to create a lua-resty module that works on top of Nginx/Lua. Using the C/C++ SDK to interact with Lua would be a last resort for us.

There are several reasons for this, including:

  • There are fewer things to go wrong (since all the upstream connections are handled by tested C code)
  • It’s the optimal way of integrating with Nginx/Lua
  • It’s quicker to make customized changes to in-house SDK (which may be different than a generic SDK)

In order to create a lua-resty-couchbase SDK, we’d need to know the KV API information, and what the other SDK’s actually do under the cover. Potentially, we could just glean this information from the Java SDK (or the C/C++ SDK when it’s ready), and duplicate that for OpenResty.

If we did use the C/C++ SDK instead of implementing the core calls using Lua, it would be completely different to the module you guys created, because it would directly interact with Lua, and would call loads of lua_xxx C functions to build Lua-compatible data that would be reusable inside Nginx/Lua.

Thank you for the suggestion, though.


thanks for you suggestion this is really helpfull or informative for me thanks again

thanks and regards

1 Like