WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 3. Протокол связи NDB Эта глава предоставляет информацию о протоколе, используемом для связи между узлами данных и узлами API в кластере NDB, чтобы выполнить различные операции, такие как запись и чтение данных и обработка записей транзакции. 3.1. Обзор протокола NDB Узлы данных и API NDB Cluster общаются друг с другом сообщениями друг другу. Отправка сообщения от одного узла и его прием другим узлом упоминается как сигнал, протокол NDB это ряд правил, управляющий форматом этих сообщений и способ, которым они передаются. Сообщение NDB, как правило, запрос или ответ. Запрос указывает, что узел API хочет выполнить операцию, включающую данные о группе (такие как поиск, вставка, обновление или удаление) или транзакции. Запрос при необходимости сопровождается информацией об индексе или ключом. Ответ, посланный узлом данных на этот запрос, указывает, сопровождается ли запрос одним или более сообщениями данных. Типы запросов. Запрос представляется как сообщение REQ. Запросы могут быть разделены на тех, которые обрабатывают данные и тех, которые обращаются с транзакциями: Запрос данных. Операции по запросу данных имеют три основных типа: Primary key lookup operations выполняются через обмен сообщениями TCKEY. Unique key lookup operations выполняются через обмен сообщениями TCINDX . Table or index scan operations выполняются через обмен сообщениями SCANTAB . Сообщения запроса данных часто сопровождаются сообщениями KEYINFO или ATTRINFO. Запросы транзакций. Они могут быть разделены на две категории: Commits and rollbacks , которые представляются сообщениями запроса TC_COMMIT и TCROLLBACK. Transaction record requests состоят из получения и освобождения записи транзакции и обработаны с помощью, соответственно, сообщения запроса TCSEIZE и TCRELEASE. Типы ответа. Ответ указывает на успех или на неудачу запроса, в котором это посылают в ответ: Ответ, указывающий на успех, представляется как сообщение CONF (confirmation) и часто сопровождается данными, которые упакованы как одно или больше сообщений TRANSID_AI. Ответ, указывающий на неудачу, представляется как сообщение REF (refusal). Для получения дополнительной информации об этих типах сообщений и их отношениях друг к другу посмотрите раздел 3.2. 3.2. Сообщения протокола NDB Эта секция описывает типы сообщений протокола NDB, их функции и структуру. Соглашения о присвоении имен. Названия сообщения построены согласно простому образцу, который должен быть очевиден из обсуждения запроса и типов ответа в предыдущей секции. Их показывают в следующей таблице: Таблица 3.1. Сообщения протокола NDB с названиями сообщений REQ, CONF и REF Тип операции Запрос (REQ) Ответ: Success (CONF) Ответ: Failure (REF) Primary Key Lookup (TCKEY) TCKEYREQ TCKEYCONF TCKEYREF Unique Key Lookup (TCINDX) TCINDXREQ TCINDXCONF TCINDXREF Table or Index Scan (SCANTAB) SCANTABREQ SCANTABCONF SCANTABREF Result Retrieval (SCAN_NEXT) SCAN_NEXTREQ SCANTABCONF SCANTABREF Transaction Record Acquisition (TCSEIZE) TCSEIZEREQ TCSEIZECONF TCSEIZEREF Transaction Record Release (TCRELEASE) TCRELEASEREQ TCRELEASECONF TCRELEASEREF CONF и REF это сокращения от confirmed и refused. Три дополнительных типа сообщений используются в некоторых случаях коммуникации междоузлия. Эти типы сообщений перечисляются здесь: KEYINFO содержит информацию о ключе, используемом в TCKEYREQ или TCINDXREQ. Это используется, когда ключевые данные не соответствуют в рамках сообщения запроса. Сообщение ATTRINFO содержит неключевые значения атрибута, которые не переданы в сообщении TCKEYREQ, TCINDXREQ или SCANTABREQ. Это используется для: Поставка значений атрибута для вставок и обновлений. Обозначение, какие признаки должны быть прочитаны для операций чтения. Определение дополнительных значений для операции удаления. Сообение TRANSID_AI содержит данные, возвращенные из операции чтения, другими словами, это набор результатов (или его часть). 3.3. Операции и сигналы В этой секции мы обсуждаем последовательность передачи сообщений, которая происходит между узлом данных и узлом API для каждой из следующих операций: Primary key lookup Unique key lookup Table scan or index scan Explicit commit of a transaction Rollback of a transaction Transaction record handling (acquisition and release) Primary key lookup. Операция, используя поиск первичного ключа, выполняется, как показано в следующей диаграмме: Рис. 3.1. Обмен сообщениями в поиске первичного ключа * и + используются здесь в значениях "ноль или больше" и "один или больше", соответственно. Шаги, составляющие этот процесс, перечислены и объяснены более подробно здесь: Узел API посылает сообщение TCKEYREQ узлу данных. Если необходимая информация о ключе, который будет использоваться, слишком большая, чтобы содержаться в TCKEYREQ, сообщение может сопровождаться любым количеством сообщений KEYINFO, несущих остающуюся ключевую информацию. Если дополнительные признаки используются для операции и превышают пространство, доступное в TCKEYREQ, или если данные нужно послать в узел данных как часть операции записи, то их посылают с TCKEYREQ как любое количество сообщений ATTRINFO. Узел данных посылает сообщение в ответ на запрос, согласно тому, имела ли операция успех или нет. Если операция была успешна, узел данных посылает сообщение TCKEYCONF узлу API. Если запрос был для операции чтения, то TCKEYCONF сопровождается сообщением TRANSID_AI, которое содержит фактические данные о результате. Если есть больше данных, чем может содержаться в одном TRANSID_AI, можно послать больше, чем одно такое сообщение. Если операция потерпела неудачу, то узел данных посылает сообщение TCKEYREF узлу API, и более сигналов не происходит, пока узел API не обращается с новым запросом. Unique key lookup. Это выполняется способом, подобным выполненному в поиске первичного ключа: C запросом обращается узел API, используя сообщение TCINDXREQ, которое может сопровождаться нолем или больше сообщений KEYINFO, а также нолем или больше сообщений ATTRINFO. Узел данных возвращает ответ, в зависимости от того, имела ли операция успех: Если операция имела успех, сообщение TCINDXCONF. Для успешной операции чтения это сообщение может сопровождаться одним или больше сообщений TRANSID_AI, несущих данные. Если операция потерпела неудачу, узел данных возвращает сообщение TCINDXREF. Обмен сообщениями, вовлеченными в поиск уникального ключа, проиллюстрирован в следующей диаграмме: Рис. 3.2. Обмен сообщениями при Unique Key Lookup Table scans and index scans. Они подобны во многих отношениях поискам первичного и уникального ключей, как показано здесь: Рис. 3.3. Обмен сообщениями при Table Scan Or Index Scan Operation. С запросом обращается узел API, используя сообщение SCAN_TABREQ, наряду с нолем или больше сообщений ATTRINFO. KEYINFO сообщения также используются с просмотрами индекса, если границы используются. Узел данных возвращает ответ, согласно тому, имела ли операция успех: Если операция имела успех, сообщение SCAN_TABCONF. Для успешной операции чтения это сообщение может сопровождаться одним или больше сообщений TRANSID_AI, несущих данные о результате. Однако, в отличие от случая с поисками на основе первичного или уникального ключа, часто необходимо передать многократные ответы узла данных. Запросы после первого сообщены узлом API, используя SCAN_NEXTREQ, который говорит узлу данных посылать следующий набор результатов (если есть больше результатов). Это показывают здесь: Рис. 3.4. Получение многократных наборов данных результатов после операции чтения таблицы или просмотра индекса Если операция потерпела неудачу, узел данных возвращает сообщение SCAN_TABREF. SCAN_TABREF также используется, чтобы сигнализировать к узлу API, что все данные послали. Committing and rolling back transactions. Процесс выполнения явной передачи следует за тем же самым общим образцом, как показано ранее. Узел API посылает сообщение TC_COMMITREQ узлу данных, который отвечает TC_COMMITCONF (при успехе) или TC_COMMITREF (если передача неудачна). Это показывают на следующей диаграмме: Рис. 3.5. Обмен сообщениями при Explicit Commit Operation Некоторые операции выполняют COMMIT автоматически, таким образом, это не требуется для каждой транзакции. Отмена транзакции также следует этому образцу. В этом случае, однако, узел API посылает сообщение TCROLLBACKTREQ узлу данных. TCROLLACKCONF или TCROLLBACKREF послано в ответ, как показано здесь: Рис. 3.6. Обмен сообщениями при отмене транзакции Handling of transaction records. Получение записи транзакции достигается, когда узел API передает сообщение TCSEIZEREQ узлу данных и получает в ответ TCSEIZECONF или TCSEIZEREF, в зависимости от того, был ли запрос успешен. Это изображено здесь: Освобождение записи транзакции также обработано, используя образец ответа запроса. В этом случае запрос узла API содержит сообщение TCRELEASEREQ и ответ узла данных использует TCRELEASECONF (указание, что запись была освобождена) или TCRELEASEREF (указание, что попытка не имела успеха). Эта серия событий проиллюстрирована в следующей диаграмме:

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.