|
Kudu C++ client API
|
#include <client.h>
Public Member Functions | |
| bool | keepalive () const |
| SerializationOptions & | enable_keepalive (bool enable) |
This class controls serialization-related parameters for a Kudu transaction handle (i.e. KuduTransaction).
One of the parameters is whether to enable sending keepalive messages for the resulting KuduTransaction handle upon deserialization. In future, the list of configurable parameters might be extended (e.g., by adding commit and abort permissions, i.e. whether a handle obtained by deserializing a handle from the string representation can be used to commit and/or abort the transaction).
| SerializationOptions & kudu::client::KuduTransaction::SerializationOptions::enable_keepalive | ( | bool | enable | ) |
Enable/disable keepalive for a handle which is the result of deserializing a previously serialized KuduTransaction handle.
Sending keepalive messages for a transaction handle deserialized from a string is disabled by default.
| [in] | enable | Whether to enable sending keepalive messages for KuduTransaction handle once it's deserialized from the string representation of a Kudu transaction handle. |
| bool kudu::client::KuduTransaction::SerializationOptions::keepalive | ( | ) | const |
This method returns the current setting keepalive behavior, i.e. whether to send keepalive messages for Kudu transaction handles.
No keepalive heartbeat messages are sent from a transaction handle if its token was created with the default "keepalive disabled" setting. The idea here is that the most common use case for using transaction tokens is of the "start topology" (see below), so it's enough to have just one top-level handle sending keepalive messages. Overall, having more than one actor sending keepalive messages for a transaction is acceptable but it puts needless load on a cluster.
The most common use case for a transaction's handle serialization/deserialization is of the "star topology": a transaction is started by a top-level application which sends the transaction token produced by serializing the original transaction handle to other worker applications running concurrently, where the latter write their data in the context of the same transaction and report back to the top-level application, which in its turn initiates committing the transaction as needed. The important point is that the top-level application keeps the transaction handle around all the time from the start of the transaction to the very point when transaction is committed. Under the hood, the original transaction handle sends keepalive messages as required until commit phase is initiated, so the deserialized transaction handles which are used by the worker applications don't need to send keepalive messages.
The other (less common) use case is of the "ring topology": a chain of applications work sequentially as a part of the same transaction, where the very first application starts the transaction, writes its data, and hands over the responsibility of managing the lifecycle of the transaction to other application down the chain. After doing so it may exit, so now only the next application has the active transaction handle, and so on it goes until the transaction is committed by the application in the end of the chain. In this scenario, every deserialized handle have to send keepalive messages to avoid automatic rollback of the transaction, and every application in the chain should set SerializationOptions::enable_keepalive to true when serializing its transaction handle into a transaction token to pass to the application next in the chain.