Author: jstephens
Date: 2007-06-11 14:38:36 +0200 (Mon, 11 Jun 2007)
New Revision: 6752
Log:
Another NDB kernel block.
Modified:
trunk/ndbapi/ndb-internals.xml
Modified: trunk/ndbapi/ndb-internals.xml
===================================================================
--- trunk/ndbapi/ndb-internals.xml 2007-06-11 08:30:10 UTC (rev 6751)
+++ trunk/ndbapi/ndb-internals.xml 2007-06-11 12:38:36 UTC (rev 6752)
Changed blocks: 3, Lines Added: 273, Lines Deleted: 13; 11400 bytes
@@ -9432,21 +9432,281 @@
<itemizedlist>
<listitem>
- <para>
- <filename>Dbtc.hpp</filename>
- </para>
+ <formalpara>
+
+ <title><filename>Dbtc.hpp</filename></title>
+
+ <para>
+ Defines the <literal>Dbtc</literal> class and associated
+ constructs, including the following:
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Trigger and index data (<literal>TcDefinedTriggerData</literal>)</title>
+
+ <para>
+ A record forming a list of active triggers for
+ each table. These records are managed by a
+ trigger pool, in which a trigger record is
+ seized whenever a trigger is activated, and
+ released when the trigger is deactivated.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Fired trigger data (<literal>TcFiredTriggerData</literal>)</title>
+
+ <para>
+ A record forming a list of fired triggers for a
+ given transaction.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Index data (<literal>TcIndexData</literal>)</title>
+
+ <para>
+ This record forms lists of active indexes for
+ each table. Such records are managed by an index
+ pool, in which each index record is seized
+ whenever an index is created, and released when
+ the index is dropped.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>API connection record (<literal>ApiConnectRecord</literal>)</title>
+
+ <para>
+ An API connect record contains the connection
+ record to which the application connects. The
+ application can send one operation at a time. It
+ can send a new operation immediately after
+ sending the previous operation. This means that
+ several operations can be active in a single
+ transaction within the transaction coordinator,
+ which is achieved by using the API connect
+ record. Each active operation is handled by the
+ TC connect record; as soon as the TC connect
+ record has sent the request to the local query
+ handler, it is ready to receive new operations.
+ The <literal>LQH</literal> connect record takes
+ care of waiting for an operation to complete;
+ when an operation has completed on the
+ <literal>LQH</literal> connect record, a new
+ operation can be started on the current
+ <literal>LQH</literal> connect record.
+ <literal>ApiConnectRecord</literal> is always
+ 256-byte aligned.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Transaction coordinator connection record
+ (<literal>TcConnectRecord</literal>)</title>
+
+ <para>
+ A <literal>TcConnectRecord</literal>) keeps all
+ information required for carrying out a
+ transaction; the transaction controller
+ establishes connections to the different blocks
+ needed to carry out the transaction. There can
+ be multiple records for each active transaction.
+ The TC connection record cooperates with the API
+ connection record for communication with the API
+ node, and with the <literal>LQH</literal>
+ connection record for communication with any
+ local query handlers involved in the
+ transaction. <literal>TcConnectRecord</literal>)
+ is permanently connected to a record in
+ <literal>DBDICT</literal> and another in
+ <literal>DIH</literal>, and contains a list of
+ active <literal>LQH</literal> connection records
+ and a list of started (but not currently active)
+ <literal>LQH</literal> connection records. It
+ also contains a list of all operations that are
+ being executed with the current TC connection
+ record. <literal>TcConnectRecord</literal> is
+ always 128-byte aligned.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Cache record (<literal>CacheRecord</literal>)</title>
+
+ <para>
+ This record is used between reception of a
+ <literal>TCKEYREQ</literal> and sending of
+ <literal>LQHKEYREQ</literal> (see
+ <xref linkend="ndb-internals-ndb-protocol-operations-signals"/>)
+ This is a separate record, so as to improve the
+ cache hit rate and as well as to minimise memory
+ storage requirements.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Host record (<literal>HostRecord</literal>)</title>
+
+ <para>
+ This record contains the <quote>alive</quote>
+ status of each node in the system, and is
+ 128-byte aligned.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Table record (<literal>TableRecord</literal>)</title>
+
+ <para>
+ This record contains the current schema versions
+ of all tables in the system.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Scan record (<literal>ScanRecord</literal>)</title>
+
+ <para>
+ Each scan allocates a
+ <literal>ScanRecord</literal> to store
+ information about the current scan.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Data buffer (<literal>DatabufRecord</literal>)</title>
+
+ <para>
+ This is a buffer used for general data storage.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Attribute information record (<literal>AttrbufRecord</literal>)</title>
+
+ <para>
+ This record can contain one (1)
+ <literal>ATTRINFO</literal> signal, which
+ contains a set of 32 attribute information
+ words.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Global checkpoint information record (<literal>GcpRecord</literal>)</title>
+
+ <para>
+ This record is used to store the
+ globalcheckpoint number, as well as a counter,
+ during the completion phase of the transaction.
+ A <literal>GcpRecord</literal> is 32-byte
+ aligned.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>TC failure record (<literal>TC_FAIL_RECORD</literal>)</title>
+
+ <para>
+ This is used when handling takeover of TC duties
+ from a failed transaction coordinator.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title></title>
+
+ <para></para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
</listitem>
<listitem>
- <para>
- <filename>DbtcInit.cpp</filename>
- </para>
+ <formalpara>
+
+ <title><filename>DbtcInit.cpp</filename></title>
+
+ <para>
+ Handles allocation and deallocation of
+ <literal>Dbtc</literal> indexes and data (includes class
+ desctructor).
+ </para>
+
+ </formalpara>
</listitem>
<listitem>
- <para>
- <filename>DbtcMain.cpp</filename>
- </para>
+ <formalpara>
+
+ <title><filename>DbtcMain.cpp</filename></title>
+
+ <para>
+ Implements <literal>Dbtc</literal> methods.
+ </para>
+
+ </formalpara>
</listitem>
</itemizedlist>
@@ -9459,8 +9719,8 @@
</para>
<para>
- This block also handles unique indexes, which must be
- co-ordinated across all data nodes simultaneously.
+ The <literal>DBTC</literal> block is implemented as the
+ <literal>Dbtc</literal> class.
</para>
<para>
@@ -9474,8 +9734,8 @@
</para>
<para>
- The <literal>DBTC</literal> block is implemented as the
- <literal>Dbtc</literal> class.
+ This block also handles unique indexes, which must be
+ co-ordinated across all data nodes simultaneously.
</para>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6752 - trunk/ndbapi | jon | 11 Jun |
