CAPITULO 15

Concorrncia
15.1 INTRODUO
Conforme explicamos na introduo ao Captulo 14, os tpicos
de concorrncia e recuperao caminham juntos, ambos fazendo
parte do tpico mais geral degerenciamento de transaes.
Agora, voltemos nossa ateno especificamente para a
concorrncia. O termo concorrncia se refere ao fato de que
os SGBDs em geral permitem que muitas transaes tenham
acesso ao mesmo banco de dados ao mesmo tempo e em um
sistema desse tipo, como bem sabemos, necessrio algum tipo
de mecanismo de controle da concorrncia para assegurar que
transaes concorrentes no interfiram umas com as outras.
Exemplos dos tipos de interferncia que podem ocorrer na
ausncia de controles adequados so descritos na Seo 15.2.
A estrutura do capitulo a seguinte:
- Na Seo 15.2, como acabamos de indicar, explicamos alguns
dos problemas que podem surgir, caso no seja fornecido um
controle de concorrncia apropriado.
- A Seo 15.3 introduz o mecanismo convencional para se
lidar com tais problemas, ou seja, o bloqueio (locking).
Nota: o bloqueio no a nica abordagem possvel para o
problema do controle da concorrncia mas de longe o mais
comumente encontrado na prtica. Algumas outras abordagens
so descritas nas anotaes s referncias [15.1], [15.3J,
[15.6-15.7] e [15.14-15.15].
- A Seo 15.4 mostra como se pode utilizar o bloqueio para
resolver os problemas descritos na Seo 15.2.
- O bloqueio infelizmente introduz seus prprios problemas
dos quais um dos mais conhecidos o deadlock. A Seo 15.5
discute essa questo.
- A Seo 15.6 descreve o conceito de serializabilidade (a
possibilidade de serializar), geralmente reconhecido como o
critrio formal de correo para a execuo de um conjunto de
transaes concorrentes.
- As Sees 15.7 e 15.8 passam ento a considerar alguns
refinamentos importantes sobre a idia bsica de bloqueio, ou
seja, os nveis de isolamento e a inteno de bloqueio.
- A Seo 15.9 descreve os recursos de SQL relevantes.
- Para encerrar, a Seo 15.10 apresenta um resumo e algumas
observaes finais.
Nota: duas observaes gerais da introduo ao Captulo 11
tambm se aplicam aqui:
411
- As idias de concorrncia, como as de recuperao, so
bastante independentes do fato de o sistema bsico ser
relacional ou de outro tipo. Porm, significativo como
ocorre com a recuperao que muitos dos primeiros trabalhos
tericos da rea tenham sido realizados em um contexto
especificamente relacional pela capacidade de definio
[15.5].
- A concorrncia, como a recuperao, um tema muito
extenso, e tudo que podemos esperar fazer neste captulo
introduzir algumas idias importantes e bsicas. Os
exerccios, as respostas e as anotaes s referncias no
final do capitulo incluem algumas descries de aspectos mais
avanados do assunto.
15.2 TRS PROBLEMAS DE CONCORRNCIA
Comeamos por considerar alguns dos problemas que qualquer
mecanismo de controle de concorrncia tem de tratar. H
essencialmente trs modos pelos quais as coisas podem dar
errado. Isto , trs modos pelos quais uma transao, ainda
que correta, pode produzir uma resposta errada se sofrer
alguma forma de interferncia de outra transao. Observe que
a transao que interfere tambm pode estar correta em si;
a intercalao descontrolada de operaes das duas transaes
corretas que produz o resultado global incorreto. (A noo de
uma transao correta em si significa que a transao no
viola a Regra Aurea consulte o Captulo 8.) Os trs
problemas so:
- O problema da atualizao perdida (lost update).
- O problema da dependncia sem COMMIT (incommited
dependency). Tambm conhecido
com leitura suja (dirty read).
- O problema da anlise inconsistente.
Consideraremos cada um por sua vez.
O problema da atualizao perdida
Considere a situao ilustrada na Figura 15.1. Essa figura
deve ser lida assim: a transao A acessa alguma tupla t no
instante ti; a transao B acessa essa mesma tupla t no
instante t2; a transao A atualiza a tupla (com base nos
valores vistos no instante ti) no tempo t3; e a transao B
atualiza a mesma tupla (com base nos valores vistos no
instante t2, que so os mesmos vistos no instante ti) no
instante t4. A atualizao da transao A perdida no
instante t4, porque a transao B a sobrescreve sem sequer
examin-la. Nota: aqui e em todo este captulo, adotaremos a
idia fictcia conveniente, ainda que faa sentido, de
atualizar uma tupla.
Transao A tempo Transao B
RETRIEVE t ti
t2 RETRIEVE t
UPDATE t t3
t4 UPDATE t
-
FIGURA 15.1 A transao A perde uma atualizao no instante
t4
412
O problema da dependncia sem COMMIT
O problema da dependncia sem COMMIT surge se uma transao
tiver permisso para ler ou pior, atualizar uma tupla que
foi atualizada por outra transao, mas que ainda no foi
validada por essa outra transao. Portanto, se o COMMIT
ainda no ocorreu, sempre existe uma possibilidade de que no
somente o COMMIT no se realize com tambm um ROLLBACK ocorra
em seu lugar e, nesse caso, a primeira transao ter visto
alguns dados que no mais existiro (e, em certo sentido,
nunca existiram). Considere as Figuras 15.2 e 15.3.
FIGURA 15.3 A transao A atualiza uma alterao sem COMMIT
no instante t2 e perde essa atualizao no instante t3
No primeiro exemplo (Figura 15.2) a transao A v uma
atualizao sem COMMIT (tambm chamada alterao sem COMMIT)
no instante t2. Esta atualizao ento desfeita no instante
t3. Portanto, a transao A est operando sobre uma suposio
falsa ou seja, a suposio de que a tupla t tem o valor
visto no instante t2, enquanto de fato ela tem o valor que
tinha antes do instante ti. Como resultado, a transao A
pode muito bem produzir uma sada incorreta. A propsito,
observe que o ROLLBACK da transao B pode no ser devido a
nenhum erro de B por exemplo, poderia resultar de uma queda
do sistema. (Alm disso, a transao A pode j ter terminado
nesse instante e, assim, a queda no provocaria a emisso de
um ROLLBACK de A tambm.)
O segundo exemplo (Figura 15.3) pior ainda. No apenas a
transao A se torna dependente de
uma alterao sem COMMIT no instante t2, mas na realidade ela
perde uma atualizao no instante t3 porque o ROLLBACK no
instante t3 faz a tupla t ser restaurada a seu valor anterior
ao instante ti. Essa
outra verso do problema da atualizao perdida.
413
Transao A tempo Transao 8
ti UPDATE t
RETRIEVE t t2


t3 ROLLBACK
1'
FIGURA 15.2 A transao A se
COMMIT no instante t2
torna dependente de uma
alterao sem
Transao A tempo Transao 8
t
1 UPOATE
t
UPDATE t t2
t3 ROLLBACK
v
O problema da anlise inconsistente
Considere a Figura 15.4 que mostra duas transaes A e B
operando sobre tuplas de contas bancrias (CON). A transao
A est totalizando saldos de contas, a transao B est
transferindo uma quantia igual a 10 da conta 3 para a conta
1. O resultado produzido por A, 110, evidentemente est
incorreto. Se A prosseguisse at gravar esse resultado de
volta no banco de dados, ela na realidade deixaria o banco de
dados em um estado inconsistente. * Dizemos que A viu um
estado inconsistente do banco de dados e, portanto, efetuou
uma anlise inconsistente. Observe a diferena entre esse
exemplo e o anterior: no h nenhuma dvida nesse caso de que
A dependente de uma alterao sem COMMIT, pois B faz o
COMMIT de todas as suas atualizaes antes de A ver a conta
CON 3.
CON1 CON2 CON3
________ 50 ________
Transao A tempo Transao 8
RETRIEVE CON 1
total = 40
RETRIEVE CON 2 : t2
total = 90
t3 RETRIEVE CON 3
t4 UPOATE CON 3
3020
t5 RETRIEVE CON 1
t6 UPDATE CON 1
4050
t7 COMMIT
RETRIEVE CON 3 : t8
total = 110, e no 120
v
EI G U R A 15.4 A transao A executa uma anlise
inconsistente
15.3 BLOQUEIO
Como indicamos na Seo 15.1, os problemas da Seo 15.2
podem ser todos resolvidos por meio de uma tcnica de
controle de concorrncia chamada bloqueio. A idia bsica
simples: quando uma transao necessita de uma garantia de
que um objeto no qual est interessada em geral, uma tupla
de banco de dados no mudar de algum modo enquanto ela
estiver ativa, a transao adquire um bloqueio sobre esse
objeto. O efeito do bloqueio impedir que outras transaes
atuem sobre o objeto em questo e portanto, em particular,
impedir que elas alterem o objeto. Desse modo, a primeira
transao capaz de executar seu processamento tendo a
certeza de que o objeto em questo permanecer em um estado
estvel durante o tempo que essa transao desejar.
* A respeito dessa possibilidade (isto , gravar o resultado
de novo no banco de dados), claro que necessrio supor
que no h 414 nenhuma restrio de integridade para impedir
tal gravao.
Damos agora uma explicao mais detalhada de como funciona o
bloqueio:
1. Primeiro, vamos supor que o sistema admita duas espcies
de bloqueios, os bloqueios exclusivos (bloqueios X) e os
bloqueios compartilhados (bloqueios C), definidos da maneira
indicada nos dois pargrafos seguintes. Nota: os bloqueios X
e C s vezes so chamados bloqueios de gravao (write locks)
e bloqueios de leitura (read locks), respectivamente. Vamos
supor at aviso em contrrio que os bloqueios X e C so os
nicos tipos disponveis; consulte a Seo 15.8 para ver
exemplos de outros tipos. Vamos supor tambm at aviso em
contrrio que as tuplas so a nica espcie de objeto
bloquevel; mais uma vez, consulte a Seo 15.8 para ver
outras possibilidades.
2. Se a transao A mantiver um bloqueio exclusivo (X) sobre
a tupla t, ento uma solicitao feita por uma transao
distinta B de um bloqueio de qualquer tipo sobre t ser
negada.
3. Se a transao A mantiver um bloqueio compartilhado (C)
sobre a tupla t, ento:
- Uma solicitao de uma transao distinta B de um bloqueio
X sobre t ser negada.
- Uma solicitao de alguma transao distinta B de um
bloqueio C sobre t ser concedida (ou seja, agora B tambm
manter um bloqueio C sobre t).
Essas regras podem ser resumidas de modo conveniente por meio
de uma matriz de compatibilidade de tipos de bloqueio (Figura
15.5). Essa matriz interpretada da seguinte maneira:
considere alguma tupla t; suponha que a transao A mantenha
no momento um bloqueio sobre t, conforme indicam as entradas
nos cabealhos de colunas (trao = nenhum bloqueio); e
suponha que alguma transao distinta B emita uma solicitao
de um bloqueio sobre t da maneira indicada pelas entradas
contidas no lado esquerdo (por completeza, vamos incluir
novamente o caso de nenhum bloqueio). Um N indica um
conflito (a solicitao de B no pode ser satisfeita, e B
entra em um estado de espera); um 5 indica compatibilidade
(a solicitao de B satisfeita). Evidentemente, a matriz
simtrica.
FIGURA 15.5 Matriz de compatibilidade para bloqueios dos
tipos X e C
Em seguida, introduzimos uma protocolo de acesso a dados (ou
protocolo de bloqueio) que faz uso dos bloqueios X e C que
acabamos de definir, a fim de garantir que problemas como os
que foram expostos na Seo 15.2 no possam ocorrer:*
1. Uma transao que deseja ler um tupla primeiro tem de
adquirir um bloqueio C sobre essa tupla.
2. Uma transao que deseja atualizar uma tupla primeiro deve
adquirir um bloqueio X sobre essa tupla.
Se a transao j tiver um bloqueio C sobre a tupla (como
acontecer em uma sequncia
RETRIEVE-UPADTE), a alternativa ser a de promover
obrigatoriamente esse bloqueio C ao nvel X.
Nota: pedidos de bloqueios de tuplas feitos por transaes
normalmente so implcitos; um pedido de leitura de tupla
uma solicitao implcita de um bloqueio C e um pedido de
atualizao de tupla uma solicitao implcita de um
bloqueio X sobre a tupla relevante. Alm disso, claro (como
sempre) que fazemos o termo atualizar incluir as operaes
INSERT e DELETE, bem como operaes UPDATE propriamente
ditas, mas as regras exigem alguns refinamentos secundrios
para tratar as operaes INSERT e DELETE. Vamos omitir os
detalhes aqui.
* O protocolo descrito um exemplo de bloqueio de duas fases
(two-phase locking) (discutido em detalhes na Seo 15.6).
415
x c
X N N S
C N S S
s s s
Para continuar com o protocolo:
3. Se uma solicitao de bloqueio da transao B for negada
devido a um conflito com um bloqueio j mantido pela
transio A, a transao B entrar em um estado de espera. B
esperar at que o bloqueio deA seja liberado. Nota: o
sistema precisa garantir que B no esperar para sempre (uma
condio s vezes referenciada como um livelock). Um modo
simples de fornecer essa garantia atender a todas as
solicitaes de bloqueios na ordem primeiro a chegar,
primeiro a ser atendido.
4. Os bloqueios X so mantidos at o fim da transao (COMMTT
ou ROLLBACK). Normalmente, os bloqueios C tambm so mantidos
at esse momento (porm, consulte a Seo 15.7).
15.4 UMA REVISO DOS TRS PROBLEMAS DE CONCORRNCIA
Estamos agora em condies de ver como o esquema precedente
resolve os trs problemas descritos na Seo 15.2. Novamente,
vamos consider-los um de cada vez.
O problema da atualizao perdida
A Figura 15.6 a verso modificada da Figura 15.1, mostrando
o que aconteceria execuo intercalada dessa figura sob o
protocolo de bloqueio descrito na Seo 15.3. A operao
UPDATE da transao A no instante t3 no aceita, porque
uma solicitao implcita de um bloqueio X sobre t, e essa
solicitao entra em conflito com o bloqueio C j mantido
pela transao B. Assim, A entra em estado de espera. Por
razes anlogas, B entra em estado de espera no instante t4.
Agora, as duas transaes so incapazes de prosseguir e,
portanto, no h nenhuma dvida de que alguma atualizao
possa ser perdida. Dessa forma, o bloqueio resolve o problema
da atualizao perdida reduzindo-o a outro problema! mas,
pelo menos, ele resolve o problema original. O novo problema
chamado deadlock e ser discutido na Seo 15.5.
Transao A tempo Transao 8
RETRIEVE t ti
(adquire bloqueio C sobre t) -
- t2 RETRIEVE t
- (adquire bloqueio C sobre t)
UPDATE t t3 -
(solicita bloqueio X sobre t) -
espera -
espera t4 UPDATE t
espera (solicita bloqueio X sobre t)
espera espera
espera espera
espera espera
FIGURA 15.6 Nenhuma atualizao perdida, mas ocorre um
deadlock no instante t4
O problema da dependncia sem COMMIT
As Figuras 15.7 e 15.8 a seguir so, respectivamente, verses
modificadas das Figuras 15.2 e 15.3, mostrando o que
aconteceria s execues intercaladas dessas figuras sob o
protocolo de bloqueio da Seo 15.3. A operao da transao
A no instante t2 (RETRIEVE na Figura 15.7, UPDATE na Figura
15.8)
416 no aceita em nenhum dos dois casos, porque uma
solicitao implcita de um bloqueio sobre t, e tal
pedido entra em conflito com o bloqueio x j mantido por B;
assim, A entra em estado de espera. Ela permanece nesse
estado at que B atinja seu trmino (seja com COMMIT ou
ROLLBACK), quando o bloqueio de B liberado e A pode
continuar. Nesse ponto, A v um valor sob GOMMIT (seja o
valor anterior a B, se terminar com um ROLLBACK, ou ento o
valor aps B, caso contrrio). Em qualquer caso, A j no
depender de uma atualizao sem COMMIT.
Transao A tempo Transao B
ti UPDATE t
(adquire bloqueio X sobre t)
RETRIEVE t t2
(solicita bloqueio C sobre t)
espera
espera t3 COMMIT / ROLLBACK
espera 1 (libera bloqueio X sobre t)
prossegue : RETRIEVE t t4
(adquire bloqueio C sobre t)
FIGURA 15.7 A transao A impedida de ver uma alterao sem
COMMITno instante t2
Transao A tempo Transao B
ti UPDATE t
(adquire bloqueio X sobre t)
UPOATE t t2
(solicita bloqueio X sobre t)
espera
espera t3 COMMIT / ROLLBACK
espera 1 (libera bloqueio X sobre t)
prossegue : UPDATE t t4
(adquire bloqueio X sobre t)
FIGURA 15.8 A transao A impedida de atualizar uma
alterao sem COMMIT no instante t2
O problema da anlise inconsistente
A Figura 15.9 uma verso modificada da Figura 15.4,
mostrando o que aconteceria em uma execuo intercalada dessa
figura sob o protocolo de bloqueio da Seo 15.3. A
atualizao (UPDATE) da transao B no instante t6 no
aceita, porque uma solicitao implcita de um bloqueio X
sobre CON 1, e tal solicitao entra em conflito com o
bloqueio C j mantido por A; assim, B entra em estado de
espera. Da mesma forma, a leitura de A no instante t7 tambm
no aceita, porque uma solicitao implcita de um
bloqueio C sobre CON 3, e essa solicitao entra em conflito
com o bloqueio X j mantido por B. Assim, A tambm entra em
estado de espera. Novamente, portanto, o bloqueio resolve o
problema original (no caso, o problema da anlise
inconsistente) forando um deadlock. Mais uma vez, consulte a
Seo 15.5.
417
COM 1 CON2 CON3
Transao A tempo Transao B
RETRIEVE CON 1 : ti
(adquire bloqueio C sobre CON 1)
total = 40
RETRIEVE CON 2 : t2
(adquire bloqueio C sobre CON 2)
total = 90
t3 RETRIEVE CON 3
(adquire bloqueio C sobre CON 3)
t4 UPDATE CON 3
(adquire bloqueio X sobre CON 3)
3020
t5 RETRIEVE COM 1
(adquire bloqueio C sobre COM 1)
t6 LJPDATE CON 1
(solicita bloqueio X sobre COM 3)
espera
RETRIEVE COM 3 : ti espera
(solicita bloqueio C sobre COM 3) espera
espera espera
espera espera
FIGURA 1 5.9 A anlise inconsistente evitada mas ocorre um
deadlock no instante t7
15.5 DEADLOCK
Vimos agora como os bloqueios podem ser usados para resolver
os trs problemas bsicos da concorrncia. Infelizmente,
porm, tambm vimos que o bloqueio pode introduzir seus
prprios problemas, principalmente o problema de deadlock.
Dois exemplos de deadlock foram dados na seo anterior. A
Figura 15.10 mostra uma verso um pouco mais geral do
problema: nessa figura, ri e r2 devem representar quaisquer
objetos bloqueveis, no necessariamente tuplas de bancos de
dados (consulte a Seo 15.8), e as instrues LOCK ...
EXCLUSIVE se destinam a representar quaisquer operaes que
adquiram bloqueios (exclusivos), implcita ou explicitamente.
O deadlock uma situao na qual duas ou mais transaes
esto em estado de espera simultnea, cada uma esperando que
uma das outras libere um bloqueio antes de poder prosseguir.*
A Figura 15.10 mostra um deadlock envolvendo duas transaes,
mas tambm so possveis, ao menos em princpio, deadlocks
envolvendo trs, quatro, ... transaes. Porm, observamos
que experincias com o System R parecem mostrar que na
prtica os deadlocks quase nunca envolvem mais de duas
transaes [15.8].
Se ocorrer um deadlock, desejvel que o sistema o detecte e
o interrompa. Detectar um deadlock envolve detectar um ciclo
no Grafo de Espera (isto , o grafo de quem est esperando
por quem consulte o Exerccio 15.4). Interromper o
deadlock envolve escolher uma das transaes participantes
ou seja, uma das transaes do ciclo no grafo como vtima e
fazer o ROLLBACK, liberando assim seus bio418 * O deadlock
tambm referenciado na literatura de forma um pouco mais
vistosa, como deadly embrace.
FIGURA 15.10 Um exemplo de deadlock
queios e, portanto, permitindo o prosseguimento de alguma
outra transao. Nota: na prtica, nem todos os sistemas
detectam de fato os deadlocks. Alguns apenas usam um
mecanismo de tempo de espera e assumem simplesmente que uma
transao que no tenha realizado qualquer trabalho durante
um perodo de tempo prescrito est em um deadlock.
A propsito, observe que a vtima falhou e ento sofreu o
ROLLBACK sem culpa alguma. Alguns sistemas reinicializaro de
forma automtica essa transao desde o incio, supondo que
as condies que causaram o deadlock provavelmente no se
repetiro. Outros sistemas apenas enviaro um cdigo de
exceo de vtima de deadlock de volta aplicao; caber
ento ao programa lidar com a situao de algum modo
elegante. A primeira dessas abordagens claramente
prefervel do ponto de vista do programador de aplicaes.
Porm, ainda que o programador s vezes tenha de se envolver,
sempre desejvel ocultar o problema do usurio final, por
razes bvias.
15.6 SERIALIZABILIDADE
Temos agora as bases para explicar a noo crucial de
serializabilidade. A serializabilidade o critrio de
correo geralmente aceito para a execuo de um dado
conjunto de transaes. Mais precisamente, uma dada execuo
de um conjunto de transaes considerada correta se for
serializvel isto , se produz o mesmo resultado de alguma
execuo serial das mesmas transaes, executadas uma de cada
vez. A justificativa para essa assertiva a seguinte:
1. Transaes individuais so consideradas corretas ou
seja, elas supostamente transformam um estado correto do
banco de dados em outro estado correto.
2. Por essa razo, a execuo das transaes uma de cada vez
em qualquer ordem serial tambm correta qualquer ordem
serial porque transaes individuais so consideradas
independentes umas das outras.
3. Portanto, uma execuo intercalada correta se
equivalente a alguma execuo serial isto , se ela
serializvel.
Voltando aos exemplos da Seo 15.2 (Figuras 15.1 a 15.4),
podemos ver que o problema em cada caso foi o fato de que a
execuo intercalada no era serializvel isto , a
execuo intercalada nunca era equivalente execuo de A
depois B ou B depois A. Alm disso, o efeito do esquema de
bloqueio discutido na Seo 15.3 foi exatamente forar a
serializabilidade em cada caso. Nas Figuras 15.7 e 15.8, a
execuo intercalada era equivalente aB depoisA. Nas Figuras
15.6 e 15.9, ocorreu um deadlock, implicando que uma das duas
transaes sofreria ROLLBACK e seria presumivelmente
executada outra vez mais tarde. Se A for a transao qude
sofre ROLLBACK, ento mais uma vez a execuo intercalada
se tornar equivalente a B depois A. 419
Transao A tempo Transao B
LOCK ri EXCLUSIVE ti -
- t2 LOCK r2 EXCLUSIVE
LOCK r2 EXCLUSIVE t3 -
espera
espera t4 LOCK ri EXCLUSIVE
espera espera
espera espera
v
Terminologia: dado um conjunto de transaes, qualquer
execuo dessas transaes, intercaladas ou no, chamada
escalonamento. Um escalonamento serial a execuo das
transaes uma de cada vez sem intercalao. Um escalonamento
no-serial um escalonamento intercalado (ou simplesmente um
escalonamento no-serial). Dois escalonamentos so ditos
equivalentes se com certeza produzem o mesmo resultado,
qualquer que seja o estado inicial do banco de dados. Assim,
um escalonamento correto (isto , serializvel) se
equivalente a algum escalonamento serial.
Vale a pena observar que dois escalonamentos seriais
diferentes envolvendo o mesmo conjunto de transaes poderiam
perfeitamente produzir resultados distintos e, portanto, que
dois escalonamentos intercalados diferentes envolvendo essas
transaes tambm poderiam produzir resultados diferentes, e
ainda assim serem ambos considerados corretos. Por exemplo,
suponha que a transao A seja da forma Somar 1 a x e a
transao B seja da forma Duplicar x (onde x algum item
no banco de dados). Suponha tambm que o valor inicial de x
seja 10. Ento, o escalonamento A depois B resulta em x = 22,
enquanto o escalonamento serial B depois A resulta em x = 21.
Esses dois resultados so igualmente corretos e qualquer
escalonamento que seja com certeza equivalente a A depoisB ou
B depoisA tambm estar correto do mesmo modo. Consulte o
Exerccio 15.3 no final deste captulo.
O conceito de serializabilidade foi introduzido em primeiro
lugar (embora no com esse nome) por Eswaran et ai. na
referncia [15.5]. O mesmo artigo tambm provou um importante
teorema, chamado teorema do bloqueio de duas fases, que
enunciamos rapidamente a seguir:*
Se todas as transaes obedecerem ao protocolo do bloqueio
de duas fases, ento todos os escalonamentos intercalados
possveis sero serializveis.
Por sua vez, o protocolo do bloqueio de duas fases o
seguinte:
1. Antes de operar sobre qualquer objeto (por exemplo, uma
tupla de banco de dados), uma transao deve adquirir um
bloqueio sobre esse objeto.
2. Depois de liberar um bloqueio, uma transao nunca deve
adquirir outros bloqueios.
Uma transao que obedece a esse protocolo tem ento duas
fases, uma fase de aquisio de bloqueio ou fase de
crescimento e uma fase de liberao do bloqueio ou de
encolhimento. Nota: na prtica, a fase de encolhimento
frequentemente compactada em uma nica operao COMMIT (ou
ROLLBACK) no final da transao. Na verdade, o protocolo de
acesso a dados que vimos na Seo 15.3 pode ser considerado
uma forma robusta do protocolo de bloqueio de duas fases.
A noo de serializabilidade de grande ajuda para se pensar
com clareza nessa rea potencialmente confusa. Por isso,
oferecemos alguns comentrios adicionais sobre a questo.
Seja 1 um escalonamento intercalado envolvendo algum conjunto
de transaes TI, T2, ... Tn. Se 1 for serializvel, ento
existir algum escalonamento serial S envolvendo Ti, T2, ...
Tn tal que 1 seja equivalente a S. S dita uma serializao
de 1. Como j vimos, S no necessariamente nico isto ,
um determinado escalonamento intercalado pode ter mais de uma
serializao.
Sejam agora Ti e Tj duas transaes quaisquer do conjunto Ti,
T2, ... Tn. Suponha, sem perda de generalidade, que Ti
precede Tj na serializao S. Assim, no escalonamento
intercalado 1, o efeito tem de ser como se Ti realmente fosse
executado antes de Tj. Em outras palavras, uma caracterizao
informal mas muito til da serializabilidade que, se A
e B so duas transaes quaisquer envolvidas em algum
escalonamento serializvel, ento A precede logicamente B ou
B precede logicamente A nesse escalonamento; ou seja, ou B
pode ver a sada de A ou A pode ver a sada de B. (Se A
atualizar os recursos r, s, ... t e se B vir qualquer desses
recursos como uma entrada, ento B ver todos eles como so
aps serem atualizados por A, ou ver todos eles como eram
antes de serem atualizados por A e no uma mistura das duas
coisas.) Inversamente, se o efeito no for como se A tivesse
sido executada antes de B ou como se B tivesse sido executada
antes de A, ento o escalonamento no ser serializvel e no
estar correto.
Concluindo, vale a pena enfatizar que, se alguma transao A
no tiver duas fases (isto , no obedecer ao protocolo de
bloqueio de duas fases), ento sempre ser possvel construir
alguma outra transao B que possa ser executada intercalada
com A, de modo a produzir um escalonamento geral que no seja
420 O bloqueio de duas fases nada tem a ver com o COMMIT de
duas fases eles simplesmente tm nomes semelhantes.
serializvel e no esteja correto. Agora, no interesse da
reduo da conteno de recursos e, portanto, para melhorar o
desempenho e o rendimento, os sistemas reais em geral
permitem a construo de transaes que no tenham duas fases
ou seja, transaes que liberam bloqueios prematuramente
(antes do COMMIT) e depois continuam a adquirir outros
bloqueios. No entanto, deve ficar claro que essas transaes
so uma proposta arriscada; com efeito, permitir que uma
determinada transao A no seja de duas fases corresponde a
apostar que nenhuma transao interferente B jamais
coexistir com A no sistema (se isso acontecer, o sistema
poder gerar respostas erradas).
15.7 NIVEIS DE ISOLAMENTO
A expresso nvel de isolamento usada para designar o que
poderia ser descrito informalmente como o grau de
interferncia que uma dada transao est preparada para
tolerar por parte de transaes concorrentes. Ora, para
garantir a serializabilidade, nenhuma interferncia pode ser
aceita! Em outras palavras, o nvel de isolamento tem de ser
o mximo possvel. Porm, conforme indicamos no final da
seo anterior, os sistemas reais em geral admitem que
transaes operem em nveis de isolamento abaixo desse
mximo, por uma variedade de razes pragmticas.
Nota: conforme sugere o pargrafo precedente, o nvel de
isolamento geralmente considerado como uma propriedade de
uma transao. No h de fato nenhuma razo pela qual uma
determinada transao no deva operar em diferentes nveis ao
mesmo tempo em partes distintas do banco de dados, pelo menos
em princpio. Contudo, por simplicidade, continuaremos a
pensar no nvel de isolamento como uma propriedade no mbito
da transao.
E possvel definir muitos nveis diferentes de isolamento. A
referncia [15.9j e o padro de SQL definem apenas quatro
nveis cada um, enquanto o DB2 aceita atualmente apenas dois.
De modo geral, quanto mais alto o nvel de isolamento, menor
a interferncia (e mais baixa a concorrncia); quanto mais
baixo o nvel de isolamento, maior a interferncia (e mais
alta a concorrncia). A ttulo de exemplo, consideramos os
dois nveis admitidos pelo DB2, chamados estabilidade de
cursor (cursor stability) e leitura repetvel (repeatable
read), respectivamente. A leitura repetvel (RR repeatable
read) o nvel mximo; se todas as transaes operarem nesse
nvel, ento todos os escalonamentos sero serializveis (as
explicaes nas Sees 15.3 e 15.4 estavam supondo
tacitamente esse nvel de isolamento). Em contraste, sob a
estabilidade de cursor (CS cursor stability), se uma
transao Ti:
- Obtm a possibilidade de endereamento para alguma tupla t,
e portanto:
- Adquire um bloqueio sobre t, e ento:
- Abandona sua possibilidade de endereamento para t sem
atualiz-la, e assim:
- No promove seu bloqueio ao nvel X e, desse modo:
- Esse bloqueio pode ser liberado sem ter de esperar pelo fim
da transao.
Porm, note que alguma outra transao T2 agora pode
atualizar t e comprometer a alterao. Se a transao Ti
voltar mais tarde e examinar outra vez t, ela ver essa
alterao e, portanto, poder de fato ver um estado
inconsistente do banco de dados. Por outro lado, sob a
leitura repetvel (RR), todos os bloqueios de tuplas no
apenas os bloqueios X so mantidos at o fim da transao e
o problema que acabamos de mencionar no poder ocorrer.
Surgem alguns pontos importantes:
1. O problema anterior no o nico problema que pode
ocorrer sob CS apenas o mais fcil de explicar porm,
infelizmente ele sugere que RR s necessrio no caso quase
improvvel de que uma dada transao precise examinar a mesma
tupla duas vezes. Ao contrrio, h argumentos suge Conforme
explicamos no Captulo 4, ela faz isso definindo um cursor
que aponte para a tupla da o nome estabilidade de
cursor. Para sermos precisos, devemos mencionar tambm que o
bloqueio que Ti adquire sobre t no DB2 um bloqueio de
atualizao (U update) e no um bloqueio C (ver a
referncia [4.20]). 421
- IX: igual a IC; alm disso, Tpoderia atualizar tuplas
individuais em R e, dessa forma, definir bloqueios X sobre
essas tupias.
- C: T pode tolerar leitores concorrentes, mas no
atualizadores concorrentes em R. A prpria T no atualizar
quaisquer tuplas em R.
- CIX: combina C e IX; isto , Tpode tolerar leitores
concorrentes mas no atualizadores concorrentes em R; alm
disso, Tpoderia atualizar tuplas individuais em R e, por
isso, definir bloqueios X sobre essas tuplas.
- X: T no pode tolerar qualquer acesso concorrente a R. A
prpria T poderia ou no atualizar tu- pias individuais em R.
As definies formais desses cinco tipos de bloqueios so
dadas por um verso ampliada da matriz de compatibilidade de
tipos de bloqueios discutida pela primeira vez na Seo 15.3.
Consulte a Figura 15.11.
FIGURA 15. 11 Matriz de compatibilidade estendida para
incluir intenes de bloqueios
Um enunciado mais preciso do protocolo de inteno de
bloqueio seria:
1. Antes de uma determinada transao poder adquirir um
bloqueio C sobre uma dada tupla, primeiro ela deve adquirir
um bloqueio IC ou mais forte (ver a seguir) sobre a varivel
de relao que contm essa tupla.
2. Antes de uma determinada transao poder adquirir um
bloqueio X sobre uma dada tupla, primeiro ela deve adquirir
um bloqueio IX ou mais forte (ver a seguir) sobre a varivel
de relao que contm essa tupla.
(Porm, observe que essa ainda no uma definio completa.
consulte a anotao referncia [15.91.)
Explicamos a seguir a noo de fora relativa de bloqueio
mencionada no protocolo anterior. Observe o grafo de
precedncia na Figura 15.12. Dizemos que o tipo de bloqueio
L2 mais forte isto , ele est em uma posio mais alta
no grafo que o tipo de bloqueio Li se e s se, sempre que
houver um N (conflito) na coluna Li da matriz de
compatibilidade para uma determinada linha, tambm haver um
N na colunaL2 para a mesma linha (consulte a Figura 15.11.)
Observe que uma solicitao de bloqueio que falhar para um
dado tipo de bloqueio certamente falhar para um tipo de
bloqueio mais forte (o que implica ser sempre mais seguro
utilizar um tipo de bloqueio que seja mais forte que o
estritamente necessrio). Observe tambm que C no mais
forte que IX ou vice-versa.
Vale a pena observar que, na prtica, os bloqueios no nvel
de varivel de relao exigidos pelo protocolo de inteno de
bloqueio em geral sero adquiridos de forma implcita. Por
exemplo, para uma transao somente de leitura, o sistema
provavelmente adquirir um bloqueio IC implcito sobre cada
varivel de relao qual a transao tiver acesso. No caso
de uma transao de atualizao, bem provvel que ela
adquira bloqueios IX. Contudo, o sistema provavelmente tambm
ter de fornecer uma ins- 423
x cix ix c ic
X N N N N N S
CIX N N N N S S
IX N N S N S S
C N N N S S S
IC
N
s
S
s
S
s
S
s
S
s
S
s

x
v
CIX
v
C IX
v
Ic
FIGURA 15.12 Grafo de precedncia de tipos de bloqueios
truo LOCK explcita de alguma espcie, a fim de permitir
que as transaes adquiram bloqueios C, X ou CIX no nvel de
varivel de relao, se desejarem. Uma instruo desse tipo
admitida, por exemplo, pelo DB2 (embora somente nos casos de
bloqueios C e X, mas no de bloqueios CIX).
Fechamos esta seo com um comentrio sobre a escalada de
bloqueios, que implementada em muitos sistemas e representa
uma tentativa de estabelecer um equilbrio entre os
requisitos conflitantes de concorrncia elevada e baixa
sobrecarga de gerenciamento de bloqueio. A idia bsica que
quando o sistema atinge um limiar predefinido,
automaticamente ele substitui um conjunto de bloqueios de
granularidade fina por um nico bloqueio de granularidade
mais grossa por exemplo, trocando um conjunto de bloqueios
C no nvel de tuplas individuais e convertendo um bloqueio IC
sobre a varivel de relao que contm as tuplas em um
bloqueio C. Essa tcnica parece funcionar bem na prtica.
15.9 RECURSOS DE SQL
A SQL padro no fornece qualquer recurso explcito de
bloqueio (na verdade, ela no menciona de forma alguma o
bloqueio como tal). Porm, exige que a implementao fornea
as garantias usuais quanto interferncia, ou quanto
ausncia de interferncia, entre transaes em execuo
concorrente. Especificamente, ela exige que atualizaes
feitas por uma determinada transao Ti no sejam visveis
para qualquer transao T2 distinta a menos que, e at que, a
transao Ti se encerre com um COMMIT. O trmino com um
COMMIT faz com que todas as atualizaes efetuadas pela
transao se tornem visveis para outras transaes. O
trmino com ROLLBACK faz com que todas as atualizaes
realizadas pela transao sejam canceladas.
Nota: o que foi dito pressupe que todas as transaes so
executadas no nvel de isolamento READ COMMITTED, REPEATABLE
READ ou SERIALIZABLE (ver a subseo imediatamente seguinte).
As consideraes especiais se aplicam a transaes executadas
no nvel READ UNCOMMITTED, que (a) tenham permisso para
executar leituras sujas mais urna vez, consulte a
subseo logo a seguir mas (b) devam ser definidas como
READ ONLY (conforme observamos no Captulo 14).
Nveis de isolamento
Vimos no Captulo 14 que a SQL inclui urna instruo SET
TRANSACTION que usada para definir certas caractersticas
da prxima transao a ser iniciada. Uma dessas
caractersticas o nvel de isolamento. Os nveis possveis
so READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ ou
SERIALIZABLE.* O padro SERIALIZABLE; se algum dos outros
trs for especificado, a implementao ser livre para
atribuir algum nvel mais alto, onde mais alto definido
de acordo com a ordem
SERIALIZABLE > REPEATABLE READ > READ COMMITTED > READ
UNCOMMITTED.
SERIALIZABLE no uma boa palavra-chave nesse caso, pois ela
corresponde a escalonamentos que supostamente devem ser
serializveis, e no transaes. Um termo melhor poderia ser
simplesmente TWO PHASE, significando que a transao obedece-
424 r (ou ser forada a obedecer) ao protocolo de bloqueio
de duas fases.
2
Se todas as transaes forem executadas no nvel de
isolamento SERIALIZABLE (o default), ento a execuo
intercalada de qualquer conjunto de transaes concorrentes
ter a garantia de ser serializvel. Entretanto, se qualquer
transao for executada em um nvel de isolamento menor,
ento a serializabilidade poder ser violada de vrios modos
diferentes. O padro define trs maneiras especficas pelas
quais a serializabilidade poderia ser violada, ou seja,
leitura suja (dirty read), leitura no repetvel
(nonrepeatable read) e fantasmas:
- Leitura suja: suponha que a transao Ti execute uma
atualizao em alguma linha. Ento, a transao T2 le essa
linha e a transao Ti termina em seguida, com um ROLLBACK. A
transao T2 enviou assim uma linha que no existe mais, e
que em certo sentido nunca existiu (porque a transao Ti na
verdade nunca foi executada).
- Leitura no repetvel: suponha que a transao Ti leia uma
linha, depois a transao T2 atualize essa linha, e a
transao Ti leia uma vez mais a mesma linha. Agora, a
transao Ti leu duas vezes a mesma linha, mas viu dois
valores diferentes para ela.
- Fantasmas: suponha que a transao Ti leia o conjunto de
todas as linhas que satisfazem a alguma condio (por
exemplo, todas as linhas de fornecedores que satisfazem
condio de que a cidade do fornecedor Paris). Suponha
ainda que a transao T2 insira em seguida uma nova linha que
satisfaz mesma condio. Se Ti repetir sua solicitao de
leitura, ver uma linha que no existia antes uma linha
fantasma.
Os vrios nveis de isolamento so definidos em termos de
quais das violaes de serializabilidade descritas eles
permitem. Esses nveis esto resumidos na Figura 15.13 (S
significa que a violao indicada pode ocorrer, e N
significa que no pode).
FIGURA 15.13 Nveis de isolamento de SQL
Surge uma pergunta bvia: como o sistema pode impedir a
ocorrncia de fantasmas? A resposta que ele precisa
bloquear o caminho de acesso usado para obter os dados em
questo. Por exemplo, no caso mencionado anteriormente a
respeito dos fornecedores de Paris, se acontecer de o caminho
de acesso ser um ndice das cidades de fornecedores, ento o
sistema dever bloquear a entrada Paris nesse ndice. Tal
bloqueio impedir a criao de fantasmas, pois essa criao
exigiria que o caminho de acesso (a entrada de ndice, em
nosso exemplo) fosse atualizado. Consulte a referncia
[14.12] para detalhes adicionais.
Encerramos esta seo enfatizando o ponto de que a operao
REPEATABLE READ de SQL e a leitura repetvel (RR) do DB2
no so a mesma coisa. De fato, a operao RR do DB2 igual
operao SERIALIZABLE de SQL.
15.10 RESUMO
Examinamos a questo de controle de concorrncia. Comeamos
observando trs problemas que podem surgir em uma execuo
intercalada dc transaes concorrentes, se esse controle no
estiver presente o problema da atualizao perdida, o
problema da dependncia sem COMMIT e o problema da anlise
inconsistente. Todos esses problemas surgem de escalonamentos
que no so serializveis isto , no-equivalentes a algum
escalonamento serial envolvendo as mesmas transaes. 425
nvel de isolamento dirty read nonrepeatable read phantom
READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE
S
N
N
N
S
S
N
N
S
S
S
N
A tcnica mais difundida para lidar com tais problemas o
bloqueio. H dois tipos bsicos de bloqueios, compartilhados
(C) e exclusivos (X). Se uma transao tiver um bloqueio C
sobre um objeto, outras transaes tambm podero obter um
bloqueio C sobre esse objeto, mas no um bloqueio X; se a
transao tiver um bloqueio X sobre um objeto, nenhuma outra
transao poder obter qualquer tipo de bloqueio sobre o
objeto. Introduzimos ento um protocolo para o uso desses
bloqueios, a fim de assegurar que no possam ocorrer
problemas da atualizao perdida (etc.): adquirir um bloqueio
C sobre tudo que for lido, adquirir um bloqueio X sobre tudo
que for atualizado e conservar todos os bloqueios at o fim
da transao. Esse protocolo impe a serializabilidade.
O protocolo que acabamos de descrever uma forma forte
(embora comum) do protocolo de bloqueio de duas fases.
Podemos mostrar que, se todas as transaes obedecerem a esse
protocolo, ento todos os escalonamentos sero serializveis
o teorema do bloqueio de duas fases. Um escalonamento
serializvel implica que, se A e B so duas transaes
quaisquer envolvidas nessa escalonamento, ento A pode ver a
sada de B ou B pode ver a sada de A. Infelizmente, o
protocolo de bloqueio de duas fases pode levar a deadlocks.
Os deadlocks so resolvidos escolhendo-se uma das duas
transaes que chegaram ao deadlock como vtima e efetuando-
se o ROLLBACK dessa transao (liberando assim todos os seus
bloqueios).
No possvel garantir que algo mais fraco que a
serializabilidade total seja seguro. Contudo, em geral os
sistemas permitem que as transaes operem em um nvel de
isolamento que de fato inseguro, com o objetivo de reduzir
a conteno de recursos e aumentar a vazo (throughput) das
transaes. Descrevemos um determinado nvel inseguro, ou
seja, a estabilidade de cursor (essa a expresso usada pelo
DB2; a expresso anloga em SQL READ COMMITTED).
Em seguida, consideramos brevemente a questo de
granularidade de bloqueio e a idia associada de inteno de
bloqueio. Em essncia, antes que uma transao possa adquirir
um bloqueio de qualquer espcie sobre algum objeto, digamos
uma tupla de banco de dados, primeiro ela deve adquirir uma
inteno de bloqueio apropriada (pelo menos) sobre o pai
desse objeto (isto , a varivel de relao recipiente, no
caso de uma tupla). Na prtica, essas intenes de bloqueios
normalmente sero adquiridas de modo implcito, da mesma
forma que bloqueios C e X sobre tuplas costumam ser
adquiridos implicitamente. Entretanto, devem ser fornecidas
instrues LOCK explcitas de alguma espcie, a fim de
permitir a uma transao adquirir bloqueios mais fortes
(quando necessrio) que aqueles adquiridos de forma
implcita.
Finalmente, esboamos o suporte de controle de concorrncia
de SQL. Basicamente, a SQL no fornece qualquer capacidade
explcita de bloqueio. Contudo, ela admite vrios nveis de
isolamento READ UNCOMMITTED, READ COMMITTED, REPEATABLE
READ e SERIALIZABLE - os quais o SGBD provavelmente
implementar por meio de bloqueios nos bastidores.
Conclumos esta parte do livro com outro comentrio breve
sobre a importncia da integridade. Quando dizemos
informalmente que o banco de dados correto, o que queremos
dizer que ele no viola qualquer restrio de integridade
conhecida. Ento, claro que um sistema que no oferece
muito no sentido de suporte de integridade ter apenas uma
idia muito fraca do que significa para o banco de dados
estar correto. Tendo em vista que afirmamos no Captulo 14
que recuperao significava a recuperao at um estado
previamente conhecido como correto, e neste captulo
afirmamos que a concorrncia ou melhor, o controle da
concorrncia significava que um escalonamento serializvel
transforma um estado correto do banco de dados em outro
estado correto, voc pode ver que a integridade , na
realidade, uma questo muito mais fundamental que apenas a
recuperao ou a concorrncia. Na verdade, a integridade
importante at mesmo em um sistema de monousurio.
EXERCICIOS
15.1 Defina serializabilidade.
15.2 Enuncie:
a. O protocolo de bloqueio de duas fases.
b. O teorema de bloqueio de duas fases.
426
15.3 Sejam as transaes TI. T2 e T3 definidas para realizar
as seguintes operaes:
TI: Somar 1 aA.
T2: Duplicar A.
T3: Mostrar A na tela e depois definir A como uma unidade.
(Onde A algum item do banco de dados.)
a. Suponha que as transaes Ti, T2 e T3 tenham permisso
para serem executadas de modo concorrente. Se A tiver valor
inicial zero, quantos resultados corretos possveis
existiro? Enumere-os.
b. Suponha que a estrutura interna de Ti, T2 e T3 seja a
indicada a seguir. Se as transaes forem executadas sem
qualquer bloqueio, quantos escalonamentos possveis haver?
to
ti (Ti) : RETRIEVE A
t2 (T2) : RETRIEVE B
(Ti) : RETRIEVE C
- (T4) : RETRIEVE D
- (T5) : RETRIEVE A
- (T2) : RETRIEVE E
- (T2) : UPDATE E
- (T3) : RETRIEVE F
- (T2) : RETRIEVE F
- (T5) : UPDATE A
- (Ti) : COMMIT
- (T6) : RETRIEVE A
- (T5) : ROLLBACK
- (T6) : RETRIEVE C
- (T6) : UPDATE C
- (Ti) : RETRIEVE G
- (T8) : RETRIEVE H
- (T9) : RETRIEVE G
- (T9) : UPDATE G
- (T8) : RETRIEVE E
- (Ti) : COMMIT
- (T9) : RETRIEVE H
- (T3) : RETRIEVE G
- (Tio) : RETRIEVE A
- (T9) : UPDATE H
- (T6) : COMMIT
c. Com o valor inicial dado (zero) para A, existiro
escalonamentos intercalados que de fato produzam um resultado
correto e ainda no sejam serializveis?
d. Haver algum escalonamento que seja de fato serializvel,
mas que no possa ser produzido se todas as trs transaes
obedecerem ao protocolo de bloqueio de duas fases?
15.4 Representamos aqui a sequncia de eventos em um
escalonamento envolvendo as transaes Ti, T2, T12. A, B,
..., H so itens no banco de dados.
tempo
tempo
tempo
427
Ti
Ri:
T2 T3
RETRIEVE A R2: RETRIEVE A R3:
RETRIEVE
A
INTO ti ; INTO t2 ; INTO t3 ;
ti : ti +
i
;
t2 : t2 *
2
;
exibir
t3
Ul:
UPDATE
A
U2:
UPDATE
A
U3:
UPDATE
A
FROM ti ; FROM t2 ; FROM 1 ;
- (Til) : RETRIEVE C
(T12) RETRIEVE O
- (T12) : RETRIEVE C
- (T2) : UPDATE F
(Til) : UPDATE C
- (T12) : RETRIEVE A
- (Tio) : UPDATE A
- (Ti2) : UPDATE O
- (T4) : RETRIEVE G
tempo Tn
Suponha que RETRIEVE R (se bem-sucedida) adquira um
bloqueio C sobre R, e que UPDATE R (se bem-sucedida)
promova esse bloqueio ao nvel X. Suponha tambm que todos os
bloqueios sejam mantidos at o fim da transao. Haver algum
deadlock no instante tn?
15.5 Considere mais uma vez os problemas de concorrncia
ilustrados nas Figuras 15.1 a 15.4. O que aconteceria em cada
caso se todas as transaes estivessem fossem executas sob o
nvel de isolamento CS em lugar de RR?
15.6 D as definies formais e informais dos tipos de
bloqueios X, C, IX, IC, CIX.
15.7 Defina a noo de fora relativa de bloqueio e d o
grafo de precedncia correspondente.
15.8 Defina o protocolo de inteno de bloqueio. Qual a
finalidade desse protocolo?
15.9 A SQL define trs problemas de concorrncia: leitura
suja, leitura no repetvel e fantasmas. De que maneira esses
trs problemas se relacionam com os problemas de concorrncia
identificados na Seo 15.2?
15.10 Esboce um mecanismo de implementao para os protocolos
de controle da concorrncia de vrias verses descritos
brevemente na anotao referncia [15.1].
REFERNCIAS E BIBLIOGRAFIA
Alm das referncias seguintes, ver tambm as referncias
[14.2], [14.101 e (especialmente) [14.12] do Captulo 14.
15.1 R. Bayer, M. Heller e A. Reiser: Parallelism and
Recovery n Database Systems, ACM TODS 5, Nmero 2 (junho de
1980).
Conforme observamos no Captulo 14, reas de aplicaes mais
novas (por exemplo, engenharia de hardware e software) muitas
vezes envolvem requisitos complexos de processamento, para os
quais os controles clssicos de gerenciamento de transaes
descritos neste captulo e no anterior no so muito
adequados. O problemas bsico que transaes complexas
podem durar horas ou dias, em vez de apenas alguns
milissegundos no mximo, como em sistemas tradicionais. Em
consequncia disso:
1. O ROLLBACK de uma transao at o incio pode provocar a
perda de uma quantidade inaceitavelmente grande de trabalho.
2. O uso de bloqueio convencional pode provocar atrasos
inaceitavelmente longos (enquanto se espera que os bloqueios
sejam liberados).
Esse artigo um dos muitos que se preocupam com esses temas
(outros incluem as referncias [15.7], [15.11-15.13] e
[15.17]). Ele prope uma tcnica de controle de concorrncia
conhecida como bloqueio multiverso (tambm chamada leitura
multiverso, e agora implementada em vrios produtos
comerciais). A maior vantagem da tcnica que as operaes
de leitura nunca precisam esperar qualquer nmero de
leitores e um nico escritor podem operar sobre o mesmo
objeto lgico simultaneamente. Para ser mais especfico:
- As leituras nunca so retardadas (como acabamos de
afirmar).
- As leituras nunca retardam as atualizaes.
- Nunca necessrio efetuar o ROLLBACK de uma transao
somente de leitura.
- O deadlock s possvel entre transaes de atualizao.
Essas vantagens so particularmente significativas em
sistemas distribudos consulte o Captulo 20 onde as
atualizaes podem demorar um longo tempo e consultas somente
de leitura podem desse modo sofrer
428 atrasos desnecessrios (e vice-versa). A idia bsica :
- Se a transao T2 pedir para ler um objeto ao qual a
transao Ti tem acesso para atualizao, a transao T2
receber acesso a uma verso previamente com COMMIT desse
objeto. Essa verso deve existir no sistema em algum lugar
provavelmente no log para fins de recuperao.
- Se a transao T2 pedir para atualizar um objeto ao qual a
transao Ti tem acesso para leitura no momento, a transao
T2 obter acesso a esse objeto, enquanto a transao Ti
manter o acesso sua prpria verso do objeto (a qual agora
na verdade a verso anterior).
- Se a transao T2 pedir para atualizar um objeto ao qual a
transao Ti tem no momento acesso de atualizao, a
transao T2 entrar em um estado de espera* (portanto, o
deadlock e o ROLLBACK forado ainda sero possveis, como
observamos antes).
Naturalmente, a abordagem inclui controles apropriados para
assegurar que cada transao sempre ver um estado
consistente do banco de dados.
15.2 Hal Berenson et ai.: A Critique of ANSI SQL Isolation
Levels, Proc. 1995 ACM SIGMOD Int. Conf. on Management of
Data, San Jose, Calif. (maio de 1995).
Esse artigo uma crtica da tentativa do padro de SQL para
caracterizar nveis de isolamento em termos de violaes de
serializabilidade (consulte a Seo 15.9): As1 definies
deixam de caracterizar corretamente vrios nveis de
isolamento populares, inclusive as implementaes padro de
bloqueio dos nveis cobertos, O documento continua a
assinalar em particular que o padro falha ao proibir
gravaes sujas (definidas como a possibilidade de duas
transaes Ti e T2 poderem ambos executar uma atualizao na
mesma linha antes de uma ou outra transao terminar).
Parece ser verdade que o padro no probe de modo explcito
as gravaes sujas. O que ele diz na realidade o seguinte
(ligeiramente reformulado):
- A execuo de transaes concorrentes no nvel de
isolamento SERIALIZABLE tem a garantia de ser serializvel.
Em outras palavras, se todas as transaes operarem no nvel
de isolamento SERIALIZABLE, a implementao ser obrigada a
proibir gravaes sujas, pois as gravaes sujas certamente
violariam a serializabilidade.
- Os quatro nveis de isolamento garantem que... nenhuma
atualizao ser perdida. Essa afirmao apenas uma
inteno; por si ss, as definies dos quatro nveis de
isolamento no oferecem qualquer garantia desse tipo. Porm,
indicam que os definidores do padro pretendiam proibir
gravaes sujas.
- Mudanas feitas por uma transao no podem ser percebidas
por outras transaes [exceto aquelas cujo nvel de
isolamento seja READ UNCOMMITTEDI at a transao original
terminar com um COMMIT. A questo aqui : qual o significado
exato de percebidas? Seria possvel uma transao atualizar
um fragmento de dados sujos sem perceb-los?
Nota: os comentrios precedentes foram retirados da
referncia [4.19].
15.3 Philip A. Bernstein e Nathan Goodman: Timestamp-Based
Algorithms for Concurrency Control in Distributed Database
Systems, Proc. 6th Int. Conf. on Very Large Data Bases,
Montreal, Canad (outubro de 1980).
Discute uma coleo de abordagens ao controle d concorrncia,
baseadas no no bloqueio, mas no uso de selos de tempo
(timestamps). A idia bsica que se a transao A iniciar
sua execuo antes da transao B, ento o sistema deve se
comportar como se A de fato fosse executada totalmente antes
de B se iniciar (como em uma genuinamente escalonamento
serial). Assim, A nunca teria permisso para ver qualquer das
atualizaes de B; da mesma forma, A nunca deveria ter
permisso para atualizar qualquer coisa que B j tenha visto.
Tais controles podem ser impostos como a seguir. Para
qualquer solicitao determinada de banco de dados, o sistema
compara o timestamp da transao solicitante com o timestamp
da transao que recuperou ou atualizou por ltimo a tupla
solicitada. Se houver um conflito, ento a transao
solicitante poder simplesmente ser reinicializada com um
novo timestamp (como nos mtodos chamados otimistas [15.141).
* Em outras palavras, ainda podero ocorrer conflitos de
atualizao/atualizao, e faremos a suposio nesse caso de
que o bloqueio ser usado para resolver tais conflitos.
Outras tcnicas (por exemplo, ouso de timestamps [15.31)
talvez possam ser usadas
em lugar dessa. 429
Como sugere o ttulo do artigo, o uso do timestamp foi
originalmente introduzido no contexto de um sistema
distribudo (onde se percebeu que o bloqueio impunha
sobrecargas intolerveis, devido s mensagens necessrias
para testar e definir bloqueios etc.). E quase certo no ser
apropriado seu uso em um sistema no distribudo. Na verdade,
tambm h bastante ceticismo quanto sua adequao prtica
aos sistemas distribudos. Um problema bvio que cada tupla
tem de transportar o timestamp da ltima transao que a leu
(bem como o timestamp da transao que a atualizou por
ltimo); isso implica que toda leitura se torna uma gravao!
Na verdade, a referncia [14.12] afirma que os esquemas de
timestamp no passam na realidade de um caso degenerado de
esquemas de controle de concorrncia otimistas [15.141, os
quais se ressentem de seus prprios problemas.
15.4 M. W. Biasgen, J. N. Gray, M. Mitoma e T. G. Price: The
Convoy Phenomenon, ACM Operating Systems Review 13, Nmero 2
(abril de 1979).
O fenmeno de comboio um problema encontrado em bloqueios
de grande trfego, como o bloqueio necessrio para gravar um
registro no log, em sistemas com escalonamento preemptivo.
Nota: aqui, escalonamento se refere ao problema de alocar
ciclos da mquina para transaes, no intercalao de
operaes de bancos de dados de diferentes transaes, como
discutimos neste captulo.
O problema o seguinte: se uma transao T estiver mantendo
um bloqueio de trfego elevado e for detida pelo escalonador
do sistema isto , forada a um estado de espera, talvez
porque sua fatia de tempo tenha expirado ento se formar
um comboio de transaes, todas esperando por sua vez no
bloqueio de grande trfego. Quando T sair de seu estado de
espera, ela logo ir liberar o bloqueio, mas (exatamente por
que o bloqueio de trfego intenso) a prpria T
provavelmente se unir de novo ao comboio antes da prxima
transao ter terminado de usar o recurso, por essa razo no
conseguir continuar seu processamento e entrar de novo em
um estado de espera.
A raiz do problema que na maioria dos casos (no em todos)
o escalonador faz parte do sistema operacional subjacente,
no do SGBD, e portanto foi projetado com base em diferentes
suposies. Como os autores observam, um comboio, uma vez
estabelecido, tende a se manter estvel; o sistema se
encontra em um estado de superbloqueio, a maior parte dos
ciclos da mquina dedicada ao chaveamento de processos e
pouco trabalho til est sendo realizado. Uma soluo
sugerida alm da possibilidade de substituir o escalonador
conceder o bloqueio no na ordem de primeiro a chegar,
primeiro a ser atendido, mas sim em uma ordem aleatria.
15.5 K. P. Eswaran, J. N. Gray, R. A. Lorie e 1. L. Traiger:
The Notions of Consistency and Predicate Locks in a Data
Base System, CACM 19, Nmero 11 (novembro de 1976).
O artigo que primeiro abordou o assunto do controle da
concorrncia sobre uma slida base terica.
15.6 Peter Franaszek eJohn T. Robinson: Limitations on
Concurrency in Transaction Processng,ACM TODS
10, Nmero 1 (maro de 1985).
Consulte a anotao referncia [15.14].
15.7 Peter Franaszek, John T. Robinson e Alexander Thomasian:
Concurrency Control for High Contention Environments,ACM
TODS 17, Nmero 2 (junho de 1992).
Esse artigo afirma que, por vrias razes, os futuros
sistemas de processamento de transaes provavelmente
envolvero um grau de concorrncia significativamente maior
que os de hoje. Em consequncia disso, provvel que haja
uma conteno de dados bem maior em tais sistemas. Os autores
apresentam ento vrios conceitos de controle de
concorrncia [sem bloqueios] e vrias tcnicas de
escalonamento de transaes aplicveis a ambientes de alta
conteno os quais como afirmam, baseados em experimentos
com modelos de simulao podem oferecer benefcios
substanciais em tais ambientes.
15.8 J. N. Gray: Experience with the System R Lock Manager,
memorando interno do San Jose Research Laboratory da IBM
(primavera de 1980).
Na realidade, essa referncia apenas um conjunto de notas,
no um documento pronto. E suas descobertas podem estar um
tanto obsoletas agora. No obstante, contm algumas
afirmaes interessantes, entre elas as seguintes:
- O bloqueio impe mais ou menos 10% de sobrecarga sobre
transaes on-line, mais ou menos 1% nas transaes batch.
- desejvel o suporte para uma variedade de granularidades
de bloqueios.
430
- O escalonamento automtico do bloqueio funciona bem.
- Os deadlocks so raros na prtica e nunca envolvem mais de
duas transaes. Quase todos os deadlocks
(97%) poderiam ser evitados pelo suporte a bloqueios tipo U,
como faz o DB2, mas no fazia o System R.
(Os bloqueios U so definidos como compatveis com bloqueios
C, mas no com outros bloqueios U e
certamente no com bloqueios x, claro. Para obter detalhes
adicionais, consulte a referncia [4.20].)
- A leitura repetvel (RR) mais eficiente, alm de mais
segura, que a estabilidade de cursor (CS).
15.9 J. N. Gray, R. A. Lorie e G. R. Putzolu: Granularity of
Locks in a Large Shared Data Base, Proc. lst Int. Conf. on
Very Large Data Bases, Framingham, Mass.: (setembro de 1975).
O artigo que introduziu o conceito de inteno de bloqueio.
Conforme explicamos na Seo 15.8, o termo granularidade se
refere ao tamanho dos objetos que podem ser bloqueados. Como
diferentes transaes obviamente tm diferentes
caractersticas e requisitos distintos, desejvel que o
sistema fornea vrias opes de granularidade, o que de fato
acontece com muitos sistemas. Esse artigo apresenta um
mecanismo de implementao para um sistema de vrias
granularidades desse tipo, com base na inteno de bloqueio.
Elaboramos mais aqui o protocolo de inteno de bloqueio,
pois as explicaes dadas no texto do captulo foram
deliberadamente um tanto simplificadas. Em primeiro lugar, os
tipos de objetos bloqueveis no precisam estar limitados a
variveis de relaes e tuplas, como estivemos supondo antes.
Em segundo lugar, esses tipos de objetos bloqueveis no
precisam nem mesmo formar uma hierarquia estrita; a presena
de ndices e outras estruturas de acesso significa que eles
devem ser considerados como um grafo acclico direcionado.
Por exemplo, o banco de dados de fornecedores e peas poderia
conter tanto (uma forma armazenada da) varivel de relao de
peas P quanto um ndice, digamos XP, sobre o atributo P#.
Para obter as tuplas da varivel de relao P, precisamos
comear com o banco de dados geral, e depois ir diretamente
para a varivel de relao e fazer uma busca sequencial ou ir
para o ndice XP e da para as tuplas P exigidas. Assim, as
tuplas de P tm dois pais no grafo, P e XP, e ambos tm por
sua vez o banco de dados como pai.
Podemos agora enunciar o protocolo em sua forma mais geral.
- A aquisio de um bloqueio X sobre um determinado objeto
adquire implicitamente um bloqueio X sobre todos os filhos
desse objeto.
- A aquisio de um bloqueio C ou CIX sobre um dado objeto
adquire implicitamente um bloqueio C sobre todos os filhos
desse objeto.
- Antes que uma transao possa adquirir um bloqueio C ou IC
sobre um dado objeto, primeiro ela deve adquirir um bloqueio
IC (ou mais forte) sobre pelo menos um pai desse objeto.
- Antes que uma transao possa adquirir um bloqueio X, IX ou
CIX sobre um dado objeto, primeiro ela deve adquirir um
bloqueio IX (ou mais forte) sobre todos os pais desse objeto.
- Antes que uma transao possa liberar um bloqueio sobre um
dado objeto, primeiro ela deve liberar todos os bloqueios que
mantm sobre todos os filhos desse objeto.
Na prtica, o protocolo no impe tanta sobrecarga durante a
execuo quanto se poderia imaginar, porque em qualquer
instante determinado, a transao provavelmente j ter a
maior parte dos bloqueios de que necessita. Por exemplo,
provvel que um bloqueio IX, digamos, seja adquirido sobre o
banco de dados inteiro apenas uma vez, no momento da
inicializao do programa. Esse bloqueio ser ento mantido
atravs de todas as transaes executadas por todo o tempo de
durao do programa.
15.10 J. N. Gray, R. A. Lorie, G. R. Putzolu e 1. L. Traiger:
Granularity of Locks and Degrees of Consistency in a
Shared Data Base, em G. M. Nijssen (editor), Proc. IFIP TC-2
Working Conf. on Modelling in Data Base
Management Systems. Amsterdam, Pases Baixos: Norte da
Holanda/Nova York, NY.: Elsevier Science
(1976).
O artigo que introduziu o conceito de nvel de isolamento
(sob o nome de graus de consistncia).
15.11 Theo Hirder e Kurt Rothermel: Concurrency Control
Issues in Nested Transactions, The VLDBJournal
2, Nmero 1 (janeiro de 1993).
Conforme explicamos no Captulo 14, vrios autores sugeriram
a idia de transaes aninhadas. Esse artigo prope um
conjunto adequado de protocolos de bloqueio para tais
transaes.
431
15.12 1. R. Jordan,J. Banerjee e R. B. Batman: Precision
Locks, Proc. 1981 ACM SIGMOD lnt. Conf. on Management of
Data, Ann Arbor, Mich. (abril/maio de 1981).
O bloqueio de preciso um esquema de bloqueio no nvel de
tupla que garante que somente as tuplas que precisam ser
bloqueados (a fim de alcanar serializabilidade) so
realmente bloqueadas, includos os fantasmas. De fato, uma
forma daquilo que se chama em outros lugares bloqueio de
predicado [15.5]. Ele funciona (a) verificando os pedidos de
atualizaes para ver se uma tupla a ser inserida ou
eliminada satisfaz a um pedido de leitura anterior feito por
alguma transao concorrente, e (b) verificando pedidos de
leitura para ver se uma tupla que j foi inserida ou
eliminada por alguma transao concorrente satisfaz o pedido
de leitura em questo. O esquema no s muito elegante,
como os autores afirmam que ele na realidade funciona melhor
que as tcnicas convencionais (que, em geral, bloqueiam
excessivamente).
15.13 Henry F. Korth e Greg Speegle: Formal Aspects of
Concurrency Control in Long-Duration Transaction Systems
Using the NT/PV Model, ACM TODS 19, Nmero 3 (setembro de
1994).
Como observamos em outras partes (consulte, por exemplo, as
referncias [14.3b [14.9] e [14.15-14.16]), a
serializabilidade frequentemente considerada uma condio
exigente demais para se impor em certos tipos de sistemas de
processo de transaes, em especial nas reas de aplicaes
mais novas que envolvem a interao humana e, portanto,
transaes de longa durao. Esse artigo apresenta um novo
modelo de transaes chamado NT/PV (transaes aninhadas com
predicados e vises) que trata de tais preocupaes. Entre
outras coisas, o artigo mostra que o modelo padro de
transaes com serializabilidade um caso especial, define
classes de correo novas e mais teis e afirma que o novo
modelo oferece uma estrutura apropriada para a soluo de
problemas de transaes de longa durao.
15.14 H. T. Kung e John T. Robinson: On Optimistic Methods
for Concurrency Control, ACM TODS 6, Nmero 2 (junho de
1981).
Os esquemas de bloqueio podem ser descritos como pessimistas,
no sentido de que eles fazem a suposio do pior caso
possvel, de que todo fragmento de dados ao qual uma
determinada transao tenha acesso pode ser necessrio a
alguma transao concorrente e, portanto, seria melhor
bloque-lo. Em contraste, os esquemas otimistas tambm
conhecidos como esquemas de certifica o ou validao
fazem a suposio oposta de que os conflitos provavelmente
sero bastante raros na prtica. Desse modo, eles operam
permitindo que as transaes sejam executadas at a
concluso, completamente livres de obstculos, e depois
verificando no instante da operao COMMIT se ocorreu de fato
algum conflito. Em caso afirmativo, a transao responsvel
simplesmente reinicializada. Nenhuma atualizao gravada no
banco de dados antes do trmino bem-sucedido do processamento
de COMMIT; desse modo, essas reinicializaes no exigem que
quaisquer atualizaes sejam desfeitas.
Um artigo subsequente [15.6] mostrou que, sob certas
hipteses razoveis, os mtodos otimistas gozam de certas
vantagens inerentes sobre os mtodos tradicionais de
bloqueio, em termos do nvel esperado de concorrncia (isto
, nmero de transaes simultneas) que podem admitir,
sugerindo que os mtodos otimistas poderiam se transformar na
tcnica preferida em sistemas com grandes nmeros de
processadores em paralelo. (Em contraste a referncia [14.12]
afirma que os mtodos otimistas em geral so na realidade
piores que o bloqueio em situaes hotspot onde um
hotspot um item de dados atualizado com muito frequncia e
por muitas transaes distintas. Consulte a anotao
referncia [15.15] para ver uma discusso de uma tcnica que
funciona bem em hotspots.)
15.15 Patrick E. O'Neil: The Escrow Transactional Method,
ACM TODS 11, Nmero 4 (dezembro de 1986).
Considere o seguinte exemplo simples. Suponha que o banco de
dados contm um item TC representando o total em dinheiro
disponvel e suponha tambm que quase toda transao no
sistema atualize TC, subtraindo dele uma certa quantia
(correspondente a algum pagamento a ser feito). Ento, Tt
um exemplo de um hotspot, isto , um item no banco de dados
ao qual uma porcentagem significativa das transaes em
execuo no sistema tem acesso. Sob o bloqueio tradicional,
um hotspot pode rapidamente tornar-se um gargalo. Porm, o
uso do bloqueio tradicional em um item de dados como 1X
realmente um exagero. Se TC tivesse inicialmente o valor de
dez milhes de reais e cada transao individual o diminusse
(em mdia) de apenas dez reais, ento poderamos executar
essas transaes um milho de vezes e, alm disso, aplicar os
decrementos correspondentes a um milho de reais em qualquer
ordem antes de ter complicaes. Assim, no h necessidade
alguma de aplicar um bloqueio tradicional a TE. Basta
garantir que o valor atual suficientemente grande para
permitir o decremento necessrio, e ento fazer a
atualizao. (Naturalmen432 te, se a transao falhar mais
tarde, a quantia do decremento dever ser adicionada de
volta.)
O mtodo de escrow (depsito) se aplica a situaes como a
que acabamos de descrever ou seja, situaes nas quais as
atualizaes so de um certo tipo especial, e no
completamente arbitrrias. O sistema deve oferecer uma nova
espcie particular de instruo de atualizao (por exemplo,
decrementar de x, se e somente se o valor atual for maior
que y). Em seguida, ele poder executar a atualizao,
inserindo o valor do decremento x em depsito, tirando-o do
depsito no fim da transao (e consolidando a mudana se o
fim de transao for COMMIT, ou acrescentando de volta a
quantia ao total original se o fim da transao for
ROLLBACK).
O artigo descreve vrios casos em que o mtodo de depsito
pode ser utilizado. Um exemplo de produto comercial que
admite a tcnica a verso Fast Path do IMS, produzido pela
IBM. Observamos que a tcnica poderia ser considerada um caso
especial de controle de concorrncia otimista [15.14j
(contudo, note que o aspecto de caso especial o
fornecimento das instrues especiais de atualizao
crtico).
15.16 Christos Papadimitriou: The Theory of Database
Concurrency Control. Rockville, Md.: Computer Science Press
(1986).
Um texto com nfase em teoria formal.
15.17 Kenneth Salem, Hector Garcia-Molina e Jeannie Shands:
Altruistic Locking, ACM TODS 19, Nmero 1 (maro de 1994).
Prope uma extenso ao bloqueio de duas fases, de acordo com
a qual uma transao Ti que tenha concludo o trabalho com
algum fragmento de dados bloqueado, mas no pode desbloque-
lo (devido ao protocolo de bloqueio de duas fases) pode,
apesar disso, doar os dados de novo ao sistema, permitindo
assim que alguma outra transao T2 adquira um bloqueio sobre
ele. Diz-se ento que T2 est no encalo de TI. So
definidos protocolos para impedir, por exemplo, que uma
transao veja quaisquer atualizaes efetuadas por
transaes que esto em seu encalo. O bloqueio altrusta (o
termo deriva do fato de que a doao de dados beneficia
outras transaes, no a transao doadora) mostrou fornecer
mais concorrncia que o bloqueio de duas fases convencional,
especialmente quando algumas das transaes so de longa
durao.
RESPOSTAS A EXERCICIOS SELECIONADOS
15.3
a. Existem seis resultados corretos possveis, correspondendo
aos seis escalonamentos seriais possveis:
Inicialmente A = O
T1-T2-T3 : A = 1
T1-T3-T2 A = 2
T2-T1-T3 : A = 1
T2-T3-T1 A 2
T3-T1-T2 A = 4
T3-T2-T1 A = 3
Naturalmente, os seis resultados corretos possveis no so
todos distintos. Na verdade, nesse exemplo em particular os
resultados corretos possveis so todos independentes do
estado inicial do banco de dados, devido natureza da
transao T3.
b. Existem 90 escalonamentos distintos possveis. Podemos
representar as possibilidades como a seguir. (Ri, Rj, Rk
representam as trs operaes RETRIEVE, RI, R2, R3, no
necessariamente nessa ordem; do mesmo modo, tjp, Uq, Ur
representam as trs operaes UPDATE, til, U2, U3, mais uma
vez no necessariamente nessa ordem.)
Ri-Rj-Rk-Up-IJq-Ur : 3 * 2 * 1 * 3 * 2 * 1 = 36
possibilidades
Ri-Rj-Up-Rk-Uq-Ur 3 * 2 *2 * 1 * 2 * 1 24 possibilidades
Ri-Rj-Up-Uq-Rk-Ur : 3 * 2 *2 * 1 * 1 * 1 12 possibilidades
Ri-Up-Rj-Rk-Uq-lJr : 3 * 1 *2 * 1 * 2 * 1 12 possibilidades
Ri-Llp-Rj-Uq-Rk-lJr 3 * 1 *2 * 1 * 1 * 1 6 possibilidades
TOTAL = 90 combinaes
433
c. Sim. Por exemplo, o escalonamento Rl-R2-R3-U3-U2-U1 produz
o mesmo resultado (um) que dois dos seis escalonamentos
seriais possveis (Exerccio: verifique isso), e portanto vem
a ser correto para o valor inicial zero dado. Porm, deve
ficar bem claro que essa correo um mero acaso e resulta
simplesmente do fato de que o valor dos dados iniciais foi
zero e no algum outro. Como um contra-exemplo, considere o
que aconteceria se o valor inicial de A fosse dez em vez de
zero, O escalonamento RI-R2-R3-U3-U2-UI mostrado antes ainda
produziria um dos resultados genuinamente corretos? (Quais
so os resultados genuinamente corretos nesse caso?) Se no,
ento esse escalonamento no serializvel.
d. Sim. Por exemplo, o escalonamento Ri-R3-Ui-U3-R2-U2
serializvel ( equivalente ao escalonamento serial T1-T3-
T2), mas no pode ser produzida se Ti, T2 e T3 obedecerem
todas ao protocolo de bloqueio de duas fases. Ento, sob esse
protocolo, a operao R3 adquirir um bloqueio C sobre A em
nome da transao T3; a operao Ul na transao Ti no ser
portanto capaz de prosseguir at esse bloqueio ser liberado,
e isso no acontecer at a transao T3 terminar (de fato,
as transaes T3 e Ti ficaro em um deadlock quando operao
U3 for alcanada).
Esse exerccio ilustra bem claramente o seguinte ponto
importante. Dado um conjunto de transaes e um estado
inicial do banco de dados, (a) seja ALI. o conjunto de todas
os escalonamentos possveis envolvendo essas transaes; (b)
seja CORRECT o conjunto de todos os escalonamentos que tm
a garantia de produzir um estado fina! correto, ou pelo menos
o fazem a partir do estado inicial dado; (c) seja
SERIALIZABIE o conjunto de todos os escalonamentos
serializveis; e (d) seja PRODUCIBLE o conjunto de todos os
escalonamentos que podem ser produzidaos sob o protocolo de
bloqueio de duas fases. Ento, em geral:
PRODUCIBLE SERIALIZABLE CORRECT ALL (usandose para
indicar um subconjunto de).
15.4 No instante tn, nenhuma transao est fazendo qualquer
trabalho til! Existe um deadlock envolvendo as transaes
T2, T3, T9 e T8; alm disso, T4 est esperando por T9, T12
est esperando por T4, e TIO e Til esto ambas esperando por
T12. Podemos representar a situao por meio de um grafo (o
Grafo de Espera), no qual os ns representam transaes e um
segmentado orientado do n Ti ao n Tj indica que Ti est
esperando por Tj (ver Figura 15.14). Os segmentos so
identificados com o nome do item do banco de dados e o nvel
de bloqueio pelo qual eles esto esperando.
TiO Til
A(X) 1 1 C(X)
T12
O (x)
T4
0(C)
H(X)
T9 T8

E (C)
0(C)
T3 T2
F(X)
FIGURA 15.14 O Grafo de Espera para o Exerccio 15.4
15.5 O nvel de isolamento CS tem o mesmo efeito do nvel de
isolamento RRnos problemas das Figuras 15.1 a
15.3. (Porm, observe que essa afirmao no se aplica a CS
como foi implementado no DB2, graas ao uso pelo DB2 de
bloqueios U em lugar de bloqueios C [4.20].) Quanto ao
problema da anlise inconsistente (Figura 15.4), o nvel de
isolamento CS no resolve esse problema; a transao A tem de
ser executada sob RR para manter seus bloqueios at o fim da
transao. Caso contrrio, ela ainda produzir a resposta
errada. (E claro que outra alternativa poderia ser o bloqueio
de toda a varivel de relao de contas, por meio de alguma
solicitao explcita de bloqueio, se o sistema admitir tal
operao. Essa soluo funcionaria sob os nveis de
isolamento CS e RR.)
434
15.6 Consulte a Seo 15.8. Observe em particular que as
definies formais so dadas pela matriz de compatibilidade
de tipos de bloqueio (Figura 15.11).
15.9 Os trs problemas de concorrncia identificados na Seo
15.2 foram os de atualizao perdida, dependncia sem COM?
vIIT e anlise inconsistente. Desses trs:
- Atualizaes perdidas: a implementao de SQL necessria
para garantir (em todas as circunstncias) que nunca ocorram
atualizaes perdidas.
- Dependncia sem COMMIT: esse apenas outro nome para a
leitura suja.
- Anlise inconsistente: esse termo cobre tanto a leitura no
repetvel quanto os fantasmas.
15.10 A breve descrio a seguir foi tirada da referncia
[20.151. Em primeiro lugar, o sistema deve manter:
1. Para cada objeto, uma pilha de verses com COMMIT (cada
entrada da pilha dando um valor para o objeto e a
identificao da transao que estabeleceu esse valor; isto
, cada entrada da pilha consiste essencialmente em um
ponteiro para a entrada relevante no log). A pilha est em
sequncia cronolgica inversa, com a entrada mais recente na
parte superior.
2. Uma lista de identificaes de transaes para todas as
transaes com COMMIT (a lista de COMMIT).
Quando uma transao se inicia, o sistema oferece a ela uma
cpia particular da lista de COMMIT. As operaes de leitura
sobre um objeto so orientadas para a verso mais recente do
objeto produzida por uma transao nessa lista particular. Em
contraste, as operaes de atualizao so orientadas para o
objeto de dados real existente no momento (esse o motivo
pelo qual ainda necessrio testar a existncia de conflitos
de atualizao/atualizao). Quando a transao sofre COMMIT,
o sistema atualiza a lista de COMMIT e as pilhas de verses
de objetos de dados de maneira apropriada.
435