Transação e

Controle de
concorrência
Transação
– As transações são originárias dos sistemas de gerenciamento de
banco de dados.
• Neste contexto, uma transação é a execução de um “programa” que
acessa um banco de dados. 
o É um conjunto de uma ou mais operações que compõem uma
única tarefa ou unidade lógica de trabalho a ser executada.
– No contexto de um servidor de arquivo transacional (sistemas
distribuídos), uma transação é a execução de uma sequência de
requisições de cliente para operações de arquivo. 
– Do ponto de vista do cliente, uma transação é uma sequência de
operações que formam um único passo, transformando os dados do
servidor de um estado consistente para outro.
Transação
– As transações podem ser fornecidas como parte do middleware.
o O CORBA (Common Object Request Broker Architecture)
fornece a especificação de um OTS (Object Transaction
Service) com interfaces IDL (Interface Definition Language) que
permitem às transações dos clientes incluírem diversos objetos
em vários servidores.
o São fornecidas operações para o cliente especificar o início e o
fim de uma transação.
o O cliente ORB (Object Request Broker) mantém um contexto
para cada transação, o qual propaga com cada operação nessa
transação.
o No CORBA, os objetos transacionais são invocados dentro do
escopo de uma transação e geralmente têm algum meio de
armazenamento persistente associado.
Transação

Em todos esses contextos, uma

transação se aplica aos objetos
recuperáveis e se destina a ser atômica.
Transação
– Propriedades
Transação
– Propriedades
o Atomicidade - ou uma transação termina com êxito e os efeitos de
todas as suas operações são gravados nos objetos ou, se ela falhar
ou for deliberadamente cancelada, não há efeito nenhum.
o Consistência - o estado do sistema após uma transação ser
completada deve manter-se consistente.
 ou seja, leva o sistema de um estado consistente para outro
estado consistente;.
o Isolamento - cada transação deve ser realizada sem interferência
de outras transações; 
 os efeitos intermediários de uma transação não devem ser
visíveis por outras transações. 
o Durabilidade - após uma transação ter sido concluída com êxito,
todos os seus efeitos são salvos no armazenamento permanente
Transação
– Uma transação é dita distribuída quando ativa operações em
diferentes servidores.
o Um servidor assume o papel de coordenador;
 Outros servidores são chamados participantes;
o Um protocolo permitirá que os servidores se comuniquem para
decidirem em conjunto se uma transação pode ser efetivada ou
se precisa ser cancelada.
o Uma transação distribuída pode ser plana ou aninhada.
Transação
– O objetivo das transações é garantir que todos os objetos
gerenciados por um servidor permaneçam em um estado consistente
ao serem acessados por várias transações e na presença de falhas
do servidor.
– O objetivo de qualquer servidor que suporte transações é maximizar
a concorrência.
o Portanto, as transações podem ser executadas
concomitantemente, caso tenham o mesmo efeito que uma
execução serial.
 Isto é, elas são serialmente equivalentes ou serializáveis.
 Um servidor assume o papel de coordenador;
Transação
– Operações na interface Coordenador (Fig. 16.3 Coulouris)
o O coordenador fornece, a cada transação, um identificador ou TID.
o O cliente invoca o método openTransaction do coordenador para introduzir uma
nova transação
 um identificador de transação, ou TID, é alocado e retornado.
o No final de uma transação, o cliente invoca o método closeTransaction para
indicar seu final.
 Todos os objetos recuperáveis acessados pela transação devem ser salvos.
o Se, por algum motivo, o cliente quiser cancelar uma transação, ele invoca o
método abortTransaction.
 Todos os seus efeitos devem desaparecer.
Transação
– Estados de uma transação
o Uma transação é bem-sucedida, ou é cancelada, de uma de
duas maneiras:
 o cliente a cancela (usando uma chamada de
abortTransaction para o servidor), ou
 o servidor a cancela.
Transação
– Estados de uma transação
Transação
– Ações de serviço relacionadas a falhas de processo
o Se um processo servidor falha inesperadamente?
 Ele será substituído.
 O novo processo servidor:
 Cancela todas as transações não confirmadas
 Restaura os valores dos objetos com os valores produzidos pela
transação confirmada mais recentemente.
o Caso um cliente falhe inesperadamente durante uma transação,
os servidores podem:
 Fornecer um tempo de expiração a cada transação.
 Cancelar toda transação que não tiver terminado antes de
seu tempo de expiração.
Transação
– Ações de cliente relacionadas a falhas do processo servidor
o Se um servidor falhar enquanto uma transação está em
andamento?
 o cliente saberá disso quando uma das operações retornar
uma exceção, após um tempo limite.
o Se um servidor falhar e, depois, durante o andamento de uma
transação, for substituído?
 a transação não será mais válida.
 o cliente deverá ser informado como uma exceção para a
próxima operação.
o Em qualquer caso, o cliente deverá, então, formular um plano,
possivelmente consultando o usuário humano, para a conclusão
ou cancelamento da tarefa da qual a transação fazia parte.
Transação - Controle de Concorrência
– Dois problemas de transações concorrentes:
o Atualização perdida
 Ocorre quando duas transações leem o valor antigo de uma
variável e depois o utilizam para calcular o novo valor.
o Recuperações inconsistentes
 Ocorre quando uma transação de recuperação é executada
concorrentemente com uma transação de atualização.
– Esses dois problemas podem ser evitados com o uso de
execuções equivalentes em série das transações.
Transação - Controle de Concorrência
– Dois problemas de transações concorrentes:
– Exemplo: Considere transações bancárias
o Suponha que em toda parte que cada uma das operações
deposit, withdraw, getBalance e setBalance é sincronizada.
 Isto é, seus efeitos sobre a variável de instância que altera o saldo de
uma conta são atômicos.
Transação - Controle de Concorrência
– O problema da atualização perdida
o Contas bancárias A, B e C, cujos saldos iniciais são de $100, $200 e
$300 respectivamente.
o A transação T transfere um valor da conta A para a conta B.
o A transação U transfere um valor da conta C para a conta B.
o Considere que as transações T e U estão sendo executadas de forma
concorrente.
Transação - Controle de Concorrência
– O problema das Recuperações inconsistentes
o A transação V transfere uma quantia da conta A para B.
o A transação W ativa o método branchTotal para obter a soma dos saldos
de todas as contas do banco.
o Contas bancárias A, B possuem saldo de $200 cada.
Transação - Controle de Concorrência
– Equivalência serial
o A equivalência serial, como critério para uma execução
concorrente correta, evita a ocorrência de atualizações perdidas
e recuperações inconsistentes.
o Se sabemos que uma transação, dentro de um conjunto de
transações, quando é executada sozinha, tem o efeito correto,
podemos inferir:
 Se essas transações forem executadas uma por vez, em
alguma ordem, o efeito combinado também será correto.
Transação - Controle de Concorrência
– Equivalência serial
o Uma interposição das operações das transações em que o efeito
combinado é igual ao que seria se as transações tivessem sido
executadas uma por vez, em alguma ordem, é uma interposição
serialmente equivalente.
 Quando dizemos que duas transações diferentes têm o
mesmo efeito, queremos dizer que as operações de leitura
retornam os mesmos valores e que as variáveis de instância
dos objetos têm os mesmos valores no final.
Transação - Controle de Concorrência
– Equivalência serial – sobre o problema da atualização perdida
Transação - Controle de Concorrência
– Equivalência serial – sobre o problema da recuperação inconsistente
Transação - Controle de Concorrência
– Operações conflitantes
o Significa que seus efeitos combinados dependem da ordem em
que elas são executadas.
o Vamos considerar duas operações: Read e Write
Transação - Controle de Concorrência
– Operações conflitantes
o Para quaisquer duas transações, é possível determinar a ordem
dos pares de operações conflitantes nos objetos acessados por
ambas.
 A equivalência serial pode ser definida em termos de conflitos
de operação.
o Para que duas transações sejam serialmente equivalentes, é
necessário e suficiente que:
 Todos os pares de operações conflitantes das duas
transações sejam executados na mesma ordem em todos os
objetos que ambas acessam.
Transação - Controle de Concorrência
– Operações conflitantes - Exemplo
o O acesso de cada transação aos objetos i e j se dá em série com
relação um ao outro.
o No entanto, a ordem não é serialmente equivalente, pois os
pares de operações conflitantes não são executados na mesma
ordem nos dois objetos.
Transação - Controle de Concorrência
– Operações conflitantes - Exemplo
o As ordens equivalentes em série exigem uma das duas
condições a seguir:
1. T acessa i antes de U e T acessa j antes de U.
2. U acessa i antes de T e U acessa j antes de T.
Transação - Controle de Concorrência
– Equivalência serial
o A equivalência serial é usada como critério para a obtenção de
protocolos de controle de concorrência.
 Esses protocolos tentam dispor as transações em série no
acesso aos objetos.
o Três estratégias alternativas de controle de concorrência são
comumente usadas:
 Travamento
 Controle de concorrência otimista
 Ordenação de carimbo de tempo (timestamp)
Transação - Controle de Concorrência
– Três estratégias alternativas de controle de concorrência são
comumente usadas:
1. Travamento (utilizado pela maioria dos sistemas)
 O servidor configura uma trava rotulada com o identificador de
transação em cada objeto, imediatamente antes que ele seja
acessado, e remove essas travas quando a transação é
concluída.
 Somente a transação para a qual ele está travado pode
acessar esse objeto.
 O uso de travamentos pode levar ao impasse (deadlock),
Transação - Controle de Concorrência
– Três estratégias alternativas de controle de concorrência são
comumente usadas:
2. Controle de concorrência otimista
 Uma transação prossegue até que peça para ser confirmada.
 Antes da permissão o servidor checa se ela realizou
operações sobre outros objetos, evitando conflitos.
 O servidor a cancela e o cliente pode reiniciá-la.
 O objetivo da verificação é garantir que todos os objetos
estejam corretos.
Transação - Controle de Concorrência
– Três estratégias alternativas de controle de concorrência são
comumente usadas:
3. Ordenação de carimbo de tempo (timestamp)
 Antes que seja permitida a confirmação.
 O servidor registra o tempo da leitura e escrita mais recentes
de cada objeto e operação.
 O carimbo de tempo da transação é comparado com o do
objeto para determinar se ela será realizada:
 Imediatamente
 Retardada ou
 Rejeitada.
Transação - Controle de Concorrência
– Basicamente, o controle de concorrência pode ser obtido pelas
transações dos clientes:
o esperando umas às outras,
o pelo reinício de transações, após um conflito entre as operações
ter sido detectado, ou
o por uma combinação dos dois.
Transação
– Capacidade de recuperação de cancelamentos
o Os servidores devem
 Registrar os efeitos de todas as transações confirmadas
 Não registrar os efeitos de nenhuma transação cancelada.
 Mas deve impedir que ela afete outras transações concorrentes.
Transação
– Capacidade de recuperação de cancelamentos
o Dois problemas podem ocorrer com o cancelamento da
transação:
 Leituras sujas (Dirty reads)
 É causado pela interação entre uma operação de leitura em uma
transação e uma operação de escrita anterior em outra
transação, sobre o mesmo objeto.
 Escritas prematuras (Previously written)
 Relacionada à interação entre operações de escrita no mesmo
objeto, pertencentes a diferentes transações.
Transação
– Capacidade de recuperação de cancelamentos
o Leitura suja

A propriedade do isolamento das transações exige que elas

não vejam o estado não confirmado de outras transações.
Transação
– Capacidade de recuperação de cancelamentos
o Leitura suja
 Como a transação U foi confirmada antes do cancelamento
da transação T, U é não recuperável.
 Para garantir que tais situações não surjam, toda transação
(como U), que corra o risco de uma leitura suja, retarda sua
operação de confirmação.
Transação
– Capacidade de recuperação de cancelamentos
o Leitura suja – Cancelamentos em cascata
 Se quaisquer outras transações tiverem visto os efeitos
causados por uma transação cancelada ( T ), elas também
deverão ser canceladas ( U ). 
 O cancelamento destas últimas transações pode fazer
com que ainda mais transações sejam canceladas. 
 Para evitar os cancelamentos em cascata, as transações
só podem ler objetos que foram escritos por transações
confirmadas/canceladas.

Evitar cancelamentos em cascata é uma condição mais

importante do que a capacidade de recuperação.
Transação
– Capacidade de recuperação de cancelamentos
o Escritas prematuras

 Alguns sistemas de banco de dados implementam a ação de

cancelamento restaurando “imagens de antes” de todas as
escritas de uma transação
 $100 é a imagem antes da transação T
 $105 é a imagem antes da transação U
 Se U for cancelada obtemos o saldo correto $105
Transação
– Capacidade de recuperação de cancelamentos
o Escritas prematuras

 Agora, considere o caso de quando U é confirmada e depois

T é cancelada
 $100 é a imagem antes da transação T.
 Obtemos o saldo incorreto $100, U será sobreposto.
 Analogamente, se T for cancelada, e depois U for
cancelada. Obtemos o saldo incorreto, $105.
Transação
– Capacidade de recuperação de cancelamentos
o Escritas prematuras
 Para garantir resultados corretos em um esquema de
recuperação que utiliza imagens de antes as operações de
escritas devem ser retardadas até que as transações
anteriores que atualizaram os mesmos objetos tenham sido
confirmadas ou canceladas.
Transação
– Capacidade de recuperação de cancelamentos
o Execuções restritas de transações
 É o atraso das operações de leitura e escrita sobre um objeto
até que todas as transações que escreveram nesse objeto
anteriormente tenham sido confirmadas ou canceladas.
 A execução restrita de transações impõe a desejada
propriedade do isolamento.
Transação
– Capacidade de recuperação de cancelamentos
o Versões de tentativa
 Um servidor de objetos recuperáveis deve ser capaz de
remover todas as atualizações de objetos.
 Caso uma transação seja cancelada. 
 As operações de atualização são executadas em versões de
tentativa dos objetos.
 Na memória volátil. 
 Cada transação possui seu conjunto de versões de tentativa
de todos os objetos que tiver alterado.
 Todas as operações de atualização de uma transação
armazenam valores no conjunto privado próprio.
Transações aninhadas
– As transações são divididas em Planas (vistas até o momento) e
Aninhadas
Transações aninhadas
– Transação Plana
o Uma transação é dita plana porque todo o seu trabalho é feito no
mesmo nível entre uma transação openTransaction e uma
confirmação ou um cancelamento.
o Não é possível efetivar ou cancelar partes dela.
o Em uma transação plana, um cliente faz pedidos para mais de
um servidor.
 Uma transação T invoca operações nos servidores X, Y e Z.
 Na transação T cada operação é concluída antes de passar para
a próxima operação.
 Os servidores são acessados em sequencia.
Transações aninhadas
– Transações aninhadas
o As transações aninhadas ampliam o modelo de transação
anterior, permitindo que as transações sejam compostas de
outras transações.
o Assim, várias transações podem ser iniciadas dentro de uma
transação, possibilitando que as transações sejam consideradas
módulos que podem ser compostos conforme for exigido.
Transações aninhadas
– Uma subtransação aparece como atômica para sua ascendente com relação
às falhas de transação e ao acesso concorrente.
– As subtransações que estão no mesmo nível, como T1 e T2, podem ser
executadas concorrentemente, mas seu acesso a objetos comuns é
organizado em série (através da utilização de bloqueios).
– Cada subtransação pode falhar independentemente de sua ascendente e das
outras subtransações.
– Quando uma subtransação é cancelada, a transação ascendente às vezes
pode escolher uma subtransação alternativa para completar sua tarefa.
Transações aninhadas
– Por exemplo,
o Uma transação (estruturada em subtransações) para enviar uma
mensagem de correio para uma lista de destinatários.
 Cada subtransação envia a mensagem a um destinatário.
 Se uma subtransação falhar, a transação ascendente poderia
registrar o fato, e ser confirmada, utilizando a confirmação de
suas descendentes.
 A transação ascendente inicia outra transação para tentar
enviar as mensagens que não foram enviadas na primeira
vez.
Transações aninhadas
– Regras de confirmação das transações aninhadas
o Uma transação só pode ser confirmada ou cancelada depois que suas
transações descendentes tiverem sido concluídas.
o Quando uma subtransação é concluída, ela toma uma decisão
independente de ser confirmada provisoriamente ou ser cancelada. Sua
decisão de cancelar é final.
o Quando uma transação ascendente é cancelada, todas as suas
subtransações são canceladas.
 Por exemplo, se T2 é cancelada, então T21 e T211 também devem ser
canceladas, mesmo que possam ter sido confirmadas
provisoriamente.
o Quando uma subtransação é cancelada, a transação ascendente pode
decidir se vai ser cancelada ou não.
 No exemplo, T decide ser confirmada, embora T2 tenha sido
cancelada.
Transações aninhadas
– Quando a transação de nível superior é efetivada, todas as subtransações
que foram efetivadas provisoriamente também serão efetivadas, desde que
nenhuma de suas ascendentes tenha sido cancelada.
– No exemplo, a efetivação de T permite que T1 , T11, T12 sejam efetivadas.
– Mas e T21 e T211, não podem ser efetivadas pois sua ascendente T2 foi
cancelada.
– Nota: os efeitos de uma subtransação não são permanentes até que
a transação de nível superior seja efetivada.
Transações aninhadas
– Duas principais vantagens das transações aninhadas:
1. As subtransações de um nível (e suas descendentes) podem ser
executadas concorrentemente com outras subtransações de mesmo
nível na hierarquia.
o Pode possibilitar maior nível de concorrência.
o Possibilita trabalho em paralelo das subtransações (servidores
diferentes).
o Exemplo:
 Considere a operação branchTotal
 Ela pode ser implementada pela invocação de getBalance
em cada conta da agência como subtransações.
 Possibilita a execução concorrente.
 Como cada operação se aplica a uma conta diferente, não
existirão operações conflitantes.
Transações aninhadas
– Duas principais vantagens das transações aninhadas:
2. As subtransações podem ser confirmadas ou canceladas
independentemente.
o Em comparação com uma única transação, um conjunto de
subtransações aninhadas é potencialmente mais robusto.
o Exemplo:
 Considere o envio de correspondência a uma lista de
destinatário.
 Com uma transação plana, uma falha de transação causaria o
reinício da transação inteira.
 Com transações aninhadas, uma transação ascendente pode
decidir sobre diferentes ações, de acordo com o fato de uma
subtransação ter sido cancelada ou não.
Travas (Locks)
– As transações devem ser programadas de modo que seus efeitos
sobre os dados compartilhados sejam serialmente equivalentes.
o Um servidor pode obter equivalência serial das transações,
dispondo em série o acesso aos objetos.
o Um exemplo simples de mecanismo para disposição em série é
o uso de travas exclusivas (exclusive locks).

destrava A, B
Travas - two-phase locking
– A equivalência serial exige que todos os acessos de uma transação a um
objeto em particular sejam dispostos em série com relação aos acessos
feitos por outras transações.
o Todos os pares de operações conflitantes de duas transações
devem ser executados na mesma ordem.
o Para garantir isso, uma transação não pode solicitar novas
travas após ter liberado uma.
o É utilizado o travamento de duas fases (two-phase locking).
 A primeira fase de cada transação é uma fase de
crescimento, durante a qual as novas travas são adquiridas.
 Na segunda fase, as travas são liberadas (uma fase de
redução).
Travas - Strict two-phase locking
– Como as transações podem ser canceladas, são necessárias execuções
restritas para evitar
o Leituras sujas e
o Escritas prematuras.
– Sob um regime de execução restrita, uma transação que precise ler ou
escrever um objeto deve ser retardada até que outras transações que
escreveram o mesmo objeto tenham sido confirmadas ou canceladas.
– Para impor essa regra, todas as travas aplicadas durante o andamento de
uma transação são mantidas, até que a transação seja confirmada ou
cancelada (Strict two-phase locking).
– A presença do travamento impede que outras transações leiam ou escrevam
os objetos.
– Quando uma transação é confirmada, para garantir a capacidade de
recuperação, os travamentos devem ser mantidos até que todos os
objetos que ela atualizou tenham sido persistidos.
Travas - Granulidade
– É um requisito importante no controle de concorrência
o Pois a abrangência do acesso concorrente aos objetos em um servidor
será seriamente limitada, caso o controle de concorrência (por exemplo,
travas) só possa ser aplicado a todos os objetos simultaneamente.
o Considerando as transações bancárias
o Se uma só trava fosse aplicada a todas as contas de uma agência,
somente um funcionário do banco poderia realizar uma transação online
em dado momento – dificilmente essa seria uma restrição aceitável!
 A parte dos objetos à qual o acesso deve ser organizado em série
deve ser a menor possível.
 Apenas a parte envolvida em cada operação solicitada pelas transações.
 deposit e withdraw afetam o saldo de uma conta.
 branchTotal afeta todos eles.
Travas - Protocolos
– Para que os protocolos funcionem corretamente, é fundamental que cada
operação de leitura e de escrita seja atômica em seus efeitos nos objetos.
– Os protocolos de controle de concorrência são projetados para suportar
conflitos entre operações de diferentes transações sobre o mesmo objeto.
o Pois a abrangência do acesso concorrente aos objetos em um
servidor será seriamente limitada, caso o controle de concorrência
(por exemplo, travas) só possa ser aplicado a todos os objetos
simultaneamente.
– Considerando as transações bancárias
o Se uma só trava fosse aplicada a todas as contas de uma agência,
somente um funcionário do banco poderia realizar uma transação online
em dado momento – dificilmente essa seria uma restrição aceitável!
Travas
– Regras de conflito das operações de leitura e de escrita
o Se uma transação T já executou uma operação de leitura sobre um
objeto em particular, então uma transação concorrente U não deve
escrever esse objeto até que T seja confirmada ou cancelada.
o Se uma transação T já executou uma operação de escrita sobre um
objeto em particular, então uma transação concorrente U não deve ler
nem escrever esse objeto até que T seja confirmada ou cancelada.
Travas
– É preferível adotar uma das estratégias de travamento abaixo, nunca ambas:
o Controle o acesso a cada objeto
 Possibilita a existência de várias transações concorrentes lendo um
objeto
o Uma única transação escrevendo um objeto.
– Isso é normalmente referido como esquema de muitos leitores/um escritor
Travas
– Como funciona
o São usados dois tipos de travas: travas de leitura e travas de escrita.
 Antes da operação de leitura
 A transação solicita uma trava de leitura no objeto.
 Antes que a operação de escrita
 A transação solicita uma trava de escrita no objeto.
 Quando for impossível alocar uma trava imediatamente, a transação
(e o cliente) deverão esperar até que isso seja possível
 A requisição de um cliente nunca é rejeitada.
Travas
– Promoção da trava
o Refere à conversão de uma trava em uma outra mais forte – isto é, em
uma trava mais exclusiva.
Travas
– Promoção da trava
o O resultado é mais permissivo e pode possibilitar execuções de outras
transações que sejam inconsistentes com a equivalência serial.
Travas
– Promoção da trava
o Uma transação de leitura que queira se promover para trava de escrita
deve esperar as demais travas sejam liberadas.
Travas
– Regras para o uso de travas em uma implementação do travamento de duas
fases restrito (Strict two-phase locking)
Travas
– Implementação
o Implementada pelo
gerenciador de travas
o O gerenciador mantem o
conjunto de travas (tabela
hashing)
o Travas são instancias da
classe Lock e atribuidas a
um objeto em particular
Travas
– Implementação
o LockManager recebe
requisições de configurar
travas e libera-las
Travas
– Travamento de requisições aninhadas
o Um conjunto de transações aninhadas deve ser impedido de observar
efeitos parciais de quaisquer outras transações aninhadas.
o Uma transação de um conjunto é impedida de observar os efeitos
parciais de outras transações do conjunto.
Travas
– Regras de travas de transações aninhadas:
o As travas adquiridas por uma subtransação é herdada pela transação
ascendente quando quando concluída;
o As transações ascendentes não podem ser executadas
concorrentemente com suas transações descendentes;
o As subtransações no mesmo nível podem ser executadas
concorrentemente
Travas
– Aquisição e liberação de travas (transações aninhadas)
o Para que uma subtransação adquira uma trava de leitura sobre um
objeto, nenhuma outra transação ativa pode ter uma trava de escrita
sobre esse objeto, e as únicas detentoras de uma trava de escrita são
suas ancestrais.
o Para que uma subtransação adquira uma trava de escrita sobre um
objeto, nenhuma outra transação ativa pode ter uma trava de leitura ou
escrita sobre esse objeto, e as únicas detentoras de travas de leitura e
escrita sobre esse objeto são suas ancestrais.
o Quando uma subtransação é confirmada, suas travas são herdadas por
sua ascendente, permitindo que esta mantenha as travas no mesmo
modo que a descendente.
o Quando uma subtransação é cancelada, suas travas são descartadas.
Se a ascendente já possui as travas, ela pode continuar a mantê-las.
Travas
– Impasses (deadlocks)
o O impasse é um estado no qual cada membro de um grupo de
transações está esperando que algum outro membro libere uma trava.
Travas
– Impasses (deadlocks)
o Grafo ‘Espera por’
 Utilizado para representar os relacionamentos de espera entre
transações correntes
Travas
– Impasses (deadlocks)
o Prevenção de impasse:
 Travar todos os objetos no inicio da transação;
 Solicitação de travas em ordem predefinida
o Travas Upgrade;
 O Concurrency Control Service do CORBA apresenta um terceiro
tipo de trava, chamada de upgrade, cuja utilização se destina a evitar
impasses.
 Deve ser solicitado pelo cliente
o Detecção de impasse:
 Detecta ciclo no grafo ‘espera por’ (pode estar no gerenciador de
travas);
 Remove uma transação (por idade, numero de ciclos envolvidos, etc)
Travas
– Impasses (deadlocks)
o Tempo Limite (Timeouts)
 Transações são invulneráveis por um período
 Passado o período, a trava se torna vulnerável;
 Apresenta problemas:
 Pode não haver um impasse;
 Sistemas sobrecarregados poderão apresentar elevados números de
travas vulneráveis;
 É necessário decidir o tempo limite para uma transação
 Pode ser usado com detecção de impasse, se tornando muito útil;
Travas
– Impasses (deadlocks)
o Solução de impasse com timeout
 Cada trava recebe um período de tempo limitado, durante o qual ela
é invulnerável. Após esse tempo, a trava se torna vulnerável.
 Desde que nenhuma outra transação esteja competindo pelo objeto
travado, um objeto com uma trava vulnerável permanece travado.
 Entretanto, se qualquer outra transação estiver esperando para
acessar o objeto protegido por uma trava vulnerável, a trava será
quebrada (isto é, o objeto será destravado) e a transação em espera
será retomada.
 A transação cuja trava foi quebrada normalmente é cancelada.
Travas
– Impasses (deadlocks)
o Solução de impasse com timeout
Travas
– Impasses (deadlocks)
o Solução de impasse com timeout
 Existem muitos problemas no uso de tempos limites como solução
para impasses:
 O pior deles é que, às vezes, as transações são canceladas porque
suas travas se tornam vulneráveis quando outras transações estão
esperando por elas, mas, na verdade, não há nenhum impasse.
Travas
– Aumento da concorrência em esquemas de travamento
o Travamento de duas versões;
o Travas hierárquicas;
Travas
– Aumento de concorrência:
o Travamento de duas versões;
 Sistema otimista;
 Grava uma versão tentativa do objeto;
 Travas de leitura esperam caso outra trava esteja confirmando o
objeto;
 Pode causar impasses;
 Transações podem ter que esperar o serem canceladas;
 Permite mais concorrência;
 Utiliza três tipos de trava: Leitura, escrita e confirmação
Travas
– Aumento de concorrência:
o Travamento de duas versões;
Travas
– Aumento de concorrência:
o Travas hierárquicas:
 Coexistência de diferente níveis de granularidade;
 Configurar uma trava ascendente tem o mesmo efeito que configurar
todas as travas descendentes;
Travas
– Aumento de concorrência:
o Travas hierárquicas:
 Possui as seguintes travas:
 Leitura
 Escrita
 Intenção de Leitura
 Intenção de Escrita
Controle de concorrência otimista
– Motivação
o Travas podem ter um custo muito alto;
o O uso de travas pode resultar em impasses.
o As soluções para impasses não são totalmente aceitáveis para sistemas
interativos.
o Travas precisam aguardar até o final da transação para evitar cancelamento
em cascata.
Controle de concorrência otimista
– Funcionamento:
o As transações podem fluir normalmente como se não houvesse possibilidade
de conflito;
o Ao chamar a função closeTransaction é feita uma validação;
Controle de concorrência otimista
– Fases:
o Fase do trabalho
 É criada uma versão tentativa;
 Leituras são realizadas imediatamente (Pegando versão mais
recente ou versão tentativa);
 Escritas são realizadas na versão tentativa;
 Possui lista de objetos lidos e escritos;
Controle de concorrência otimista
– Fases:
o Fase de validação
 Executada na chamada da função closeTransaction;
 Verifica se há conflitos com operações de outras transações

o Fase de atualização
 Caso as alterações sejam validadas elas se tornam permanentes;
 Transações apenas de leitura são confirmadas imediatamente após a
validação;
 Transações de escrita estarão serão confirmadas após o registro em
armazenamento permanente.
Controle de concorrência otimista
– Validação de transação
o Garante que a transação é serialmente equivalente com as transações
sobrepostas;
o No inicio da fase da validação as transições ‘recebem’ um numero inteiro;
o Números sequenciais ascendentes (posição no tempo);
o Se a validação for validada com sucesso o numero permanece igual;
o Se a validação falhar ou se a transação for apenas de leitura o numero é
passado para uma transação posterior;
o Transações sempre terminam a fase de trabalho após transações com
números inferiores
Controle de concorrência otimista
– Validação de transação
o O teste de validação na transação Tv é baseado no conflito entre operações
em pares de transação Ti e Tv.
o Para que uma transação Tv seja disposta em série com relação a uma
transação sobreposta Ti, suas operações devem obedecer às seguintes
regras:
Controle de concorrência otimista
– Validação de transação
o Uma regra que garanta que apenas uma transação estará na fase de
validação e atualização garante a regra 3;
o Validação devem garantir que as regras 1 e 2 sejam obedecidas;
o Podem ser de dois tipos: backward e forward
Controle de concorrência otimista
– Validação de transação
o Validação para trás (backward):
 As operações de leitura das transações sobrepostas foram feitas
antes da validação corrente; (regra 1)
 Verifica se os objetos lidos entram em conflito com objetos escritos
de transações sobrepostas (regra 2);
 Caso positivo, a validação falha;
 Apenas a transação sendo validada pode ser cancelada;
 Operações de leitura não precisam ser validadas;
Controle de concorrência otimista
– Validação de transação
o Validação para frente (forward):
 O conjunto de escrita da transação validada é comparado com todos
os objetos lidos da transações ativas sobrepostas (fase de trabalho)
(regra 1);
 A regra 2 é satisfeita automaticamente, uma vez que as transações
ativas só escrevem após a transação validada tiver terminado;
 O conjunto de leitura das transações ativas pode mudar;
 Como as transações comparadas estão ativas, há a possibilidade de
cancelar a transação corrente ou tratar as demais;
 Opções: Adiar a validação até um momento posterior, Cancelar
todas as transações ativas, Cancelar a transação que está sendo
validada
Controle de concorrência otimista
– Inanição
o Processo de impedir que uma transação seja capaz de ser confirmada.
o Quando uma transação é cancelada,
 Normalmente, será reiniciada pelo programa cliente,
 Mas não há garantia que será validada
 Pois, sempre que é reiniciada, ela pode entrar em conflito com
outras transações no uso de objetos.
Ordenação por carimbo de tempo
– xxxxxx
o xxxxxx
 xxxxx
 xxxxx
 xxxxx
Comparação dos métodos
– xxxxxx
o xxxxxx
 xxxxx
 xxxxx
 xxxxx
Exercícios