Discusses the mechanics of transaction handling and transmission in NDB Cluster and the NDB API, and the objects used to implement these.
When transactions are sent using
are not immediately transferred to the NDB Kernel. Instead,
transactions are kept in a special send list (buffer) in the
Ndb object to which they
belong. The adaptive send algorithm decides when transactions
should actually be transferred to the NDB kernel.
The NDB API is designed as a multithreaded interface, and so it
is often desirable to transfer database operations from more
than one thread at a time. The NDB API keeps track of which
Ndb objects are active in
transferring information to the NDB kernel and the expected
number of threads to interact with the NDB kernel. Note that a
given instance of
Ndb should be
used in at most one thread; different threads should
not share the same
There are four conditions leading to the transfer of database
buffers to the NDB kernel:
The NDB Transporter (TCP/IP or shared memory) decides that a buffer is full and sends it off. The buffer size is implementation-dependent and may change between NDB Cluster releases. When TCP/IP is the transporter, the buffer size is usually around 64 KB. Since each
Ndbobject provides a single buffer per data node, the notion of a “full” buffer is local to each data node.
The accumulation of statistical data on transferred information may force sending of buffers to all storage nodes (that is, when all the buffers become full).
Every 10 milliseconds, a special transmission thread checks whether or not any send activity has occurred. If not, then the thread will force transmission to all nodes. This means that 20 ms is the maximum amount of time that database operations are kept waiting before being dispatched. A 10-millisecond limit is likely in future releases of NDB Cluster; checks more frequent than this require additional support from the operating system.
For methods that are affected by the adaptive send algorithm (such as
NdbTransaction::execute()), there is a
forceparameter that overrides its default behavior in this regard and forces immediate transmission to all nodes. See the individual NDB API class listings for more information.
The conditions listed above are subject to change in future releases of NDB Cluster.