A instrução BEGIN ... END fornece às instruções definidas nas palavras-chave BEGIN e END o status de uma instrução única.
O segundo Label poderá estar presente apenas se o primeiro Label estiver presente. Se ambos os rótulos estiverem presentes, eles deverão ser idênticos. Duas ou mais instruções rotuladas no mesmo nível podem ter o mesmo rótulo, mas isso nega parcialmente a vantagem do segundo rótulo. A vantagem é que os rótulos correspondem a cada END com o seu BEGIN de maneira não ambígua e precisa. No entanto, uma instrução rotulada aninhada em Instruções não pode ter o mesmo rótulo, porque isso torna ambíguo o comportamento das instruções ITERATE e LEAVE.
DECLARE Variable1 CHAR 'Existing variable'; -- A reference to Variable1 here returns 'Existing variable' BEGIN -- A reference to Variable1 here returns 'Existing variable' DECLARE Variable1 CHAR 'Local variable'; -- Perfectly legal even though the name is the same -- A reference to Variable1 here returns 'Local variable' END;
Se ATOMIC for especificado, apenas uma instância de um fluxo de mensagens (ou seja, um encadeamento) terá permissão para executar as instruções de uma instrução específica BEGIN ATOMIC... END (identificada por seu esquema e rótulo), a qualquer momento. Se nenhum rótulo estiver presente, o comportamento será como se um rótulo de comprimento zero tivesse sido especificado.
CREATE PROCEDURE WtiteSharedVariable1(IN NewValue CHARACTER) SharedVariableMutex1 : BEGIN ATOMIC -- Configurar novo valor para a variável compartilhada END; CREATE FUNCTION ReadSharedVariable1() RETURNS CHARACTER SharedVariableMutex1 : BEGIN ATOMIC DECLARE Value CHARACTER; -- Obter valor de variável compartilhada RETURN Value; END;
Não aninhe instruções BEGIN ATOMIC... END, direta ou indiretamente, porque isso pode levar a "impasses". Por esse motivo, não utilize uma instrução PROPAGATE a partir de um bloco atômico.
Não é necessário utilizar a construção BEGIN ATOMIC em fluxos que nunca serão implementados com mais de uma instância (mas não convém arriscar). Também é desnecessário utilizar a construção BEGIN ATOMIC em leituras e gravações para variáveis compartilhadas. O intermediário sempre grava seguramente um novo valor em, e lê seguramente o valor mais recente de, uma variável compartilhada. ATOMIC é requerido apenas quando o aplicativo está suscetível à visualização de resultados intermediários.
DECLARE LastOrderDate SHARED DATE; ... SET LastOrderDate = CURRENT_DATE; ... SET OutputRoot.XMLNSC.Data.Orders.Order[1].Date = LastOrderDate;Aqui, suponha que um encadeamento esteja atualizando periodicamente um LastOrderDate e um outro o esteja lendo periodicamente. Não há necessidade de utilizar ATOMIC, porque a segunda instrução SET sempre lê um valor válido. Se a atualização e a leitura ocorrerem em tempos muito próximos, não é possível determinar se será lido o valor novo ou antigo, mas é sempre um ou outro. O resultado nunca será constituído de lixo.
DECLARE Count SHARED INT; ... SET Count = Count + 1;Aqui, suponha que vários encadeamentos estejam executando periodicamente a instrução SET. Neste caso, é necessário utilizar ATOMIC, porque dois encadeamentos podem ler Count quase no mesmo instante e obter o mesmo valor. Ambos os encadeamentos desempenham a inclusão e ambos armazenam o mesmo valor novamente. O resultado final é, portanto, N+1 e não N+2.
O intermediário não fornece automaticamente travamento de nível mais alto que este (por exemplo, travamento abrangendo a instrução SET inteira), porque esse travamento é responsável por causar "impasses".
Você pode considerar a instrução BEGIN ... END como sendo uma construção em loop, que sempre entra em loop apenas uma vez. O efeito de uma instrução ITERATE ou LEAVE aninhada em uma instrução BEGIN ... END é, neste caso, conforme o esperado: o controle é transferido para a instrução após END. Utilizar ITERATE ou LEAVE em uma instrução BEGIN ... END é útil nos casos em que existe uma longa série de cálculos que precisam ser abandonados, porque um resultado limitado foi alcançado ou porque ocorreu um erro.