6.2 Segundo Estudo – O ACOM
6.2.2 ACOM – Gerenciamento Auto-Adapt´avel de Protocolos de Efetiva¸c˜ao
de Efetiva¸c˜ao
Ao analisar os custos de efetivar e de cancelar uma transa¸c˜ao nos protocolos PrC e PrA, pode-se notar que o PrC possui o menor custo para transa¸c˜oes efetivadas, enquanto que o PrA possui o menor custo para transa¸c˜oes canceladas. Considerando essa caracter´ıstica, em [95] foi proposto o gerenciador de transa¸c˜oes ACOM11. O ACOM ´e capaz de alterar dinamicamente o protocolo de efetiva¸c˜ao utilizado com base nas taxas de efetiva¸c˜ao e de cancelamento. Com isso o ACOM visa obter sempre o melhor custo dentre os protocolos de efetiva¸c˜ao utilizados.
Os Protocolos de Efetiva¸c˜ao
O ACOM generaliza a defini¸c˜ao dos protocolos de efetiva¸c˜ao 2PC, PrC e PrA. Seu objetivo ´e prover uma implementa¸c˜ao desses protocolos como um conjunto de componentes inter- conectados. Cada protocolo seria implementado pelo mesmo conjunto de componentes, sendo que suas principais diferen¸cas seriam expressas somente atrav´es de mudan¸cas nas suas interconex˜oes.
A Figura 6.9 mostra como os protocolos 2PC, PrC e PrA podem ser definidos no ACOM atrav´es de mudan¸cas nas conex˜oes dos componentes. O CommitManager atua como o coordenador, enviando mensagens de prepare, commit e abort 12 a cada par- ticipante – representado pelo ResourceManager – e registrando os passos do protocolo no log. O componente CommunicationManager, implementado como um barramento de comunica¸c˜ao, permite ao coordenador enviar mensagens s´ıncronas e ass´ıncronas (com ac-
knowledge e sem acknowledge, respectivamente) aos participantes. Para o coordenador
e para cada participante, existe um componente LogManager – respons´avel por prover escritas ao log do tipo force e do tipo non-force.
No ACOM, os protocolos de efetiva¸c˜ao s˜ao implementados como segue:
2PC. Para implementar esse protocolo (Figura 6.9(a)), o CommitManager envia as mensagens prepare, commit e abort de forma s´ıncrona atrav´es da interface sync do 11
ACOM ´e um acrˆonimo para o termo “self-Adaptive Component-based cOmmit Management” 12
prepare representa o pedido de voto, commit representa a decis˜ao de efetiva¸c˜ao e abort representa a decis˜ao de cancelamento
Figura 6.9: Arquitetura dos Protocolos de Efetiva¸c˜ao no ACOM
CommunicationM anager. As opera¸c˜oes de decis˜ao de efetiva¸c˜ao e de cancelamento s˜ao escritas como force no log atrav´es da interface force do LogManager. No final do protocolo, o resultado da transa¸c˜ao ´e escrita no log como non-force atrav´es da in- terface non-force do LogManager. O ResourceManager, ao receber as mensagens de prepare, commit e abort do CommitManager realiza registros correspondentes no log do tipo force.
PrA. Nessa implementa¸c˜ao (Figura 6.9(b)), a mensagem prepare e a decis˜ao de efetiva¸c˜ao s˜ao enviadas pelo CommitManager de forma s´ıncrona atrav´es da interface sync do CommunicationManager. Ao contr´ario do 2PC, a decis˜ao de cancelamento ´e enviada de forma ass´ıncrona atrav´es da mensagem asyn. No PrA, o CommitManager registra a decis˜ao de efetiva¸c˜ao como force e registra a finaliza¸c˜ao de transa¸c˜oes efetivadas como non-force. O ResourceManager registra o voto e a decis˜ao de efetiva¸c˜ao como force e a decis˜ao de cancelamento como non-force.
PrC. Nessa implementa¸c˜ao (Figura 6.9(c)), antes de enviar a mensagem prepare, o Com-
mitManager utiliza a interface initiation-log para registrar a inicializa¸c˜ao do proto-
colo como force junto ao LogManager. No PrC, a mensagem prepare e a decis˜ao de cancelamento s˜ao enviadas pelo CommitManager de forma s´ıncrona atrav´es da interface sync do CommunicationManager. Por outro lado, a decis˜ao de efetiva¸c˜ao ´e enviada de forma ass´ıncrona atrav´es da mensagem asyn. A decis˜ao de efetiva¸c˜ao ´e registrada no log como force e o final de transa¸c˜oes abortadas s˜ao registradas como
non-force. O ResourceManager registra o seu voto e a decis˜ao de cancelamento
102 Cap´ıtulo 6. Servi¸cos de Transa¸c˜oes Abertos
O Gerenciador de Comportamento
Para que o ACOM possa decidir e configurar dinamicamente o protocolo de efetiva¸c˜ao de menor custo, ele deve conhecer as taxas de efetiva¸c˜ao e de cancelamento das transa¸c˜oes que v˜ao sendo executadas. Para isso ele define um gerenciador de comportamento capaz de medir essas taxas e de aplicar a pol´ıtica de adapta¸c˜ao. Essa pol´ıtica ´e do tipo ECA (Evento/Condi¸c˜ao/A¸c˜ao), onde o Evento ´e a taxa de efetiva¸c˜ao/cancelamento, a Condi¸c˜ao especifica quando o protocolo deve ser mudado e a A¸c˜ao ´e a reconfigura¸c˜ao do mecanismo de efetiva¸c˜ao para implementar o protocolo escolhido.
Figura 6.10: Arquitetura do Gerenciador de Comportamento no ACOM
O componente BehaviourAwareness implementa a pol´ıtica de adapta¸c˜ao. Ele monitora o n´umero de transa¸c˜oes efetivadas e canceladas e decide quando o protocolo deve ser alterado. A altera¸c˜ao do protocolo ´e determinada pela regra ECA implementada pelo
BehaviourAwareness. Por exemplo, uma regra ECA poderia ser: se taxa–de–abort <
10% ent˜ao use 2PC.
Quando o BehaviourAwareness decide alterar o protocolo, ele utiliza a sua interface
change-config que est´a conectada `a interface config do componente TransactionFactory.
Ao receber a decis˜ao, o TransactionFactory conecta sua interface active-config `a con- figura¸c˜ao apropriada. Dessa forma, as pr´oximas transa¸c˜oes s˜ao criadas usando a nova configura¸c˜ao. O conjunto de configura¸c˜oes dispon´ıveis ´e listado pela interface available-
config do TransactionFactory. Cada configura¸c˜ao dispon´ıvel ´e definida individualmente
por um componente. Tx(2PC), Tx(2PC-PC) e Tx(2PC-PA) s˜ao os componentes que definem as configura¸c˜oes dos protocolos de efetiva¸c˜ao 2PC, PrC e PrA, respectivamente.
6.2.3
Limita¸c˜oes do ACOM
Apesar de ACOM ser capaz de se reconfigurar dinamicamente para obter o melhor custo dentre os protocolos de efetiva¸c˜ao 2PC, PrC e PrA, sua estrutura dificulta poss´ıveis ex- tens˜oes (como se ver´a a seguir). Dada a variedade de requisitos das aplica¸c˜oes transacio- nais, outras otimiza¸c˜oes do protocolo 2PC tˆem sido propostas na literatura, como o 1PC [3] e o NPrC [56].
Estender o ACOM para incluir novos protocolos de efetiva¸c˜ao ´e uma tarefa poss´ıvel, por´em complexa. Por exemplo, para incluir um novo protocolo ao ACOM (ex:NPrC), o programador teria que realizar as seguintes tarefas:
(i) Identificar todos os componentes envolvidos na implementa¸c˜ao do mecanismo de efetiva¸c˜ao do ACOM.
(ii) Identificar as interfaces envolvidas nas interconex˜oes entre os componentes que im- plementam o mecanismo de efetiva¸c˜ao.
(iii) Conhecer cada conex˜ao a ser criada e cada conex˜ao a ser exclu´ıda para implementar o novo protocolo.
(iv) Implementar e compilar o componente de configura¸c˜ao do novo protocolo a ser in- clu´ıdo no ACOM (ex: Tx(NPrC)).
(v) Analisar e alterar a implementa¸c˜ao do componente BehaviourAwareness para incluir a pol´ıtica de adapta¸c˜ao que considera o uso do novo protocolo.
(vi) Incluir o componente de configura¸c˜ao (Tx(NPrC)) na lista de configura¸c˜oes dispon´ıveis (available-config) da TransactionFactory.
Para realizar essas tarefas s˜ao necess´arias a an´alise detalhada do c´odigo fonte do ACOM e a modifica¸c˜ao do c´odigo que implementa um dos seus componentes – o Be-
haviourAwareness. Al´em de dif´ıcil e enfadonho, essa altera¸c˜ao de c´odigo fonte pode levar
a erros de implementa¸c˜ao do novo protocolo pondo em risco a estabilidade e a precis˜ao do servi¸co de transa¸c˜oes. Isso refor¸ca a premissa de que possuir uma arquitetura baseada em componentes n˜ao ´e garantia absoluta de facilidade de extens˜oes [35, 97].