Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
M
MariaDB
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
nexedi
MariaDB
Commits
78b0977c
Commit
78b0977c
authored
Jan 09, 2005
by
jon@gigan
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
More documentation edits in Ndb.hpp (Adaptive Send Algorithm)
parent
cd4479a7
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
31 additions
and
30 deletions
+31
-30
ndb/include/ndbapi/Ndb.hpp
ndb/include/ndbapi/Ndb.hpp
+31
-30
No files found.
ndb/include/ndbapi/Ndb.hpp
View file @
78b0977c
...
...
@@ -467,51 +467,52 @@
/**
@page secAdapt Adaptive Send Algorithm
At the time of "sending"
the
transaction
At the time of "sending"
a
transaction
(using NdbTransaction::execute()), the transactions
are in reality <em>not</em> immediately transfered to the NDB Kernel.
Instead, the "sent" transactions are only kept in a
special send list (buffer) in the Ndb object to which they belong.
The adaptive send algorithm decides when transactions should
be transfe
red to the NDB kernel.
actually be transfer
red to the NDB kernel.
The NDB API is designed as a multi-threaded interface and
it is desirable to transfer database operations from more than
The NDB API is designed as a multi-threaded 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 transfering
The NDB API keeps track of which Ndb objects are active in transfer
r
ing
information to the NDB kernel and the expected amount of threads to
interact with the NDB kernel.
Note that a
n Ndb object should be used in at most one thread.
Two
different threads should <em>not</em> use the same Ndb object.
Note that a
given instance of Ndb should be used in at most one thread;
different threads should <em>not</em> use the same Ndb object.
There are four
reasons leading to transfering
of database
operations:
There are four
conditions leading to the transfer
of database
operations
from Ndb object buffers to the NDB kernel
:
-# The NDB Transporter (TCP/IP, OSE, SCI or shared memory)
decides that a buffer is full and sends it off.
The buffer size is implementation
dependent and
m
ight change between NDB
Cluster releases.
On TCP/IP the buffer size is usually around 64
kByte and
The buffer size is implementation
-
dependent and
m
ay change between MySQL
Cluster releases.
On TCP/IP the buffer size is usually around 64
KB;
on OSE/Delta it is usually less than 2000 bytes.
In each Ndb object there is one buffer per DB node,
so this criteria of a full buffer is only
local to the connection to one DB node.
-# Statistical information on the transfered information
may force sending of buffers to all DB nodes.
-# Every 10 ms a special send-thread checks whether
Since each Ndb object provides a single buffer per storage node,
the notion of a "full" buffer is local to this storage node.
-# The accumulation of statistical data on transferred information
may force sending of buffers to all storage nodes.
-# Every 10 ms, a special transmission thread checks whether or not
any send activity has occurred. If not, then the thread will
force
sending
to all nodes.
force
transmission
to all nodes.
This means that 20 ms is the maximum time database operations
are
waiting before being sent off. The 10
millisecond limit
are
kept waiting before being sent off. The 10-
millisecond limit
is likely to become a configuration parameter in
later releases of NDB Cluster.
However, to support faster than 10 ms checks,
there has to be support from the operating system.
-# When methods that are affected by the adaptive send alorithm,
e.g. NdbTransaction::execute(), there is a force parameter
that overrides it forces the send to all nodes.
@note The reasons mentioned above are examples. These might
change in later releases of NDB Cluster.
future releases of MySQL Cluster; however, for checks that
are more frequent than each 10 ms,
additional support from the operating system is required.
-# For methods that are affected by the adaptive send alorithm
(such as NdbTransaction::execute()), there is a <var>force</var> parameter
that overrides its default behaviour in this regard and forces
immediate transmission to all nodes. See the inidvidual NDB API class
listings for more information.
@note The conditions listed above are subject to change in future releases
of MySQL Cluster.
*/
#ifndef DOXYGEN_SHOULD_SKIP_INTERNAL
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment