O conceito de transações surgiu em sistemas de gerenciamento de banco de dados [70] e posteriormente estendido para outras áreas, como nas linguagens de coordenação [74]. Implementações de espaços de tuplas modernas, como o JavaSpaces [118] e o TSpaces [83], provêem suporte a transações.
Uma transação atômica é uma abstração que assegura a execução como um todo lógico de uma seqüência de operações em um sistema (neste caso, o espaço de tuplas), garantindo que ou todas as operações da transação são refletidas corretamente no sistema (a transação é confirmada) ou nenhuma o será (a transação é cancelada por falha no processo de execução de suas operações ou pelo cancelamento espontâneo emitido pelo cliente). Portanto, uma transação no espaço de tuplas deve também ser uma seqüência de operações que leva o espaço de tuplas de um estado consiste para um outro estado também consistente. Para garantir a consistência do espaço de tuplas uma transação deve satisfazer as propriedades ACID [71]:
• atomicidade: todas as operações da transação são refletidas corretamente no sistema ou nenhuma será;
• consistência: uma transação leva o sistema de um estado consistente pra outro também consistente;
• isolamento: cada transação não tem conhecimento de outras transações concorrentes no sistema, ou seja, os efeitos intermediários de uma transação não devem ser visíveis para outras transações;
• durabilidade: depois que uma transação é executada com sucesso, as alterações efetu- adas no sistema persistem, até mesmo quando houverem falhas no mesmo.
Normalmente, a sequência de operações executadas por uma transação é delimitada por cláusulas do tipo beginTransaction e commitTransaction, que indicam o início e fim de uma transação, respectivamente. A operação commitTransaction tenta efetivar as mudanças rea- lizadas pela transação atual, propagando os resultados para o espaço de tuplas. E a operação abortTransactiondeve ser usada para cancelar os efeitos de uma transação no espaço.
A decisão pela confirmação ou não de uma transação é a fase mais crítica na execução da mesma. Esta fase visa garantir que todos os resultados de operações definidas em uma transação sejam efetivados ou, caso não seja possível, descartados. Uma das formas de ga- rantir esta característica de “tudo ou nada” é através do uso de um protocolo de confirmação atômica (atomic commit protocol), permitindo que que todos os servidores tomem a mesma decisão [70].
6.2.1 Semântica das Operações
O uso de transações afeta a semântica das operações de leitura/escrita no espaço de tu- plas. A semântica depende do modelo de controle de concorrência utilizado. Deste modo, a garantia do controle de concorrência pessimista no acesso a tuplas no espaço por transações concorrentes é provida através da redefinição da semântica das operações de leitura/escrita no espaço de tuplas. Antes de apresentar a semântica das operações no espaço de tuplas, é necessário definir formalmente alguns termos usados no texto. Uma transação T é uma seqüência de operações ho1, o2, ..., oki tal que todas são executadas ou nenhuma das opera-
ções de T apresentam um efeito permanente (Atomicidade, Consistência and Durabilidade), e nenhum efeito da transação é percebido por outras transações antes da mesma ser confir- mada (Isolamento). É dito que uma transação mantém um bloqueio de leitura sobre um tupla t quando a transação está lendo uma tupla t. Quando a transação T está removendo a tupla t é dito que a transação T mantém um bloqueio de remoção sobre a tupla t. É dito que duas transações T1e T2estão em conflito quando uma tenta adquirir o bloqueio de leitura ou
duas ou mais transações compartilham um bloqueio de leitura quando ambas transações estão mantendo o bloqueio de leitura sobre a mesma tupla t.
Dadas estas definições, redefinimos a semântica das operações de leitura/escrita no es- paço de tuplas, quando executadas dentro do contexto de uma transação, da seguinte maneira:
• out(t): uma tupla t inserida só fica visível no espaço de tuplas para outros processos após a transação T ser confirmada. No entanto, logo após a execução do out, a tupla t fica visível para o processo dentro da transação T . Se esta tupla t for removida na própria transação T , então t não será adicionada no espaço quando a sua transação T for confirmada. O mesmo acontece se a transação T for cancelada.
• rd(t) e rdp(t): a leitura de uma tupla t pode se dar logo após sua inserção, tanto no contexto da própria transação T1, quanto no espaço de tuplas. Tal tupla t lida do espaço
de tupla pode ser lida por outras transações concorrentes T2, mas não pode ser removida
por estas. Se nenhuma tupla t que combinando com o molde t estiver disponível, as operações rd e rdp se comportam de maneiras diferentes:
– A operação rd(t) sempre aguarda até que uma tupla combinando com o molde esteja disponível no espaço;
– A operação rdp(t) somente irá aguardar por uma tupla t que combine com o molde t em caso de conflito com outra transação T2, ou seja, outra transação T2 está
removendo a tupla t que combina com o molde t. Comportando-se desta maneira, se T2 for cancelada, a operação rdp(t) da transação T1 deve ser capaz de ler t.
Note que a operação rdp(t) pode ficar bloqueada até que outras transações sob conflito com a mesma sejam concluídas. Isto garante a propriedade de Isolamento de maneira conservadora.
• in(t) e inp(t): estas operações podem remover tuplas t escritas tanto no contexto da transação T1, quanto no espaço de tuplas. Uma tupla t removida do espaço de tuplas
numa transação não pode ser lida e nem removida por outras transações T2 concor-
rentes. De maneira semelhante à rd e rdp, as operações in e inp somente diferem na maneira que se comportam quando não existem tuplas t disponíveis no espaço que combinam com o molde t:
– A operação in(t) aguarda até que uma tupla t combinando com o molde t esteja disponível no espaço de tuplas.
– A operação inp(t) somente irá aguardar por uma tupla t que combine com o molde t em caso de conflito com outras transações T2, ou seja, outra transação T2 está
Note que as semânticas permitem que mesmo operações não bloqueantes como inp(t) e rdp(t) serem bloqueadas esperando por transações conflitantes serem confirmadas ou cance- lada. Isto acontece devido ao nosso modelo de concorrência pessimista, no qual uma opera- ção somente é completada dentro de uma transação se é garantida que a mesma poderia ser confirmada no futuro (ao contrário do modelo de concorrência otimista [80]), e também para manter a propriedade de Isolamento das transações.