- 
                                http://www.arquitecturadesoftware.org/blogs/hugoribeiro/archive/2006/10/16/sql-server-transactions-locking-4.aspx
                            
- 
                                http://postgresqlbr.blogspot.com/2007_05_01_archive.html- SERIALIZABLE - Fiel às características ACID, apresenta menor desempenho pois praticamente simula a execução sequencial de transações. A transação poderá ver apenas os dados já efetivados no banco antes do início da execução da transação. Isto é, não poderá por exemplo ler dados inseridos após o seu início.- REPEATABLE READ - Mais flexível, apresenta melhor desempenho em relação ao anterior. A transação poderá ler os mesmos dados várias vezes durante sua execução e o valor será o mesmo.- READ COMMITTED - Mais flexível e com melhor desempenho em relação ao anterior. A transação poderá ler os mesmos dados várias vezes durante sua execução e o valor lido será diferente caso o dado tenha sido atualizado por outra transação que tenha feito COMMIT explícito ou implícito.- READ UNCOMMITTED - Apresenta o melhor desempenho em relação às demais. No entanto não é fiel às características ACID. Neste caso a transação poderá ler os mesmos dados várias vezes durante sua execução e o valor lido será diferente caso o dado tenha sido atualizado por outra transação que tenha feito ou não COMMIT.
                            
- 
                                Essa questão é simples, basta lembrar dos princípios do protocólo 2PL“para toda transação Tx, todas as operaçõesde bloqueio de dados feitas por Tx precedema primeira operação de desbloqueio feita porTx”Como essas transações não respeitam o 2PL, não são serializáveis e consequentemente não podem ser executadas de forma concorrente.
                            
- 
                                não entendi essa questão, quando são serializáveis não quer dizer que não podem ser executadas concorrentemente?Mas a resposta diz "não são serializáveis e, portanto, não podem ser executadas concorrentemente"
                            
- 
                                Essa questão me parece tem relação com o conceito de Escalonamento (planos de execução) baseados em serialidade (serializability), conforme podemos ver a partir da página 407 do livro do Elmasri/Navathe (3a edição). O conceito de serialidade de escalonamentos (schedules) é usado para identificar se um plano S é correto quando há intercalação das operações executadas por duas transações. Se um plano de duas transações for serializável, então ele é correto, podendo ser utilizado. Um algorítimo para testar se os conflitos de um plano são sererializáveis consiste em (vide também http://en.wikipedia.org/wiki/Precedence_graph):     - Para cada transação Ti participante do plano S, criar um nó (um círculo) rotulado Ti no grafo de precedência
- Para cada caso em S em que Ti executar um ler_item(X) depois que uma Tj executar um escrever_item(X), criar uma seta (Tj —> Ti) no grafo de precedência
- Para cada caso em S em que Ti executar um escrever_item(X) depois que Tj executar um ler_item(X), criar uma seta (Tj —> Ti) no grafo de precedência
- Para cada caso em S em que Ti executar um escrever_item(X) depois que Tj executar um escrever_item(X), criar uma seta (Tj —> Ti) no grafo de precedência
- O plano S será serializável se, e apenas se, o grafo precedência não contiver ciclos
 Os ciclos mencionados se referem à situação em que uma seta vai, por exemplo, de T1 para T2 e outra vai de T2 para T1. A questão não apresenta um escalonamento para as duas transações, mas podemos ver que o primeiro passo de cada uma delas é ler a variável que é escrita no final da outra. Isso claramente causa um ciclo que em qualquer escalonamento existirá, portanto o escalonamento não seria serializável e seria não é correto, não sendo possível executar as transações concorrentemente. 
- 
                                Segundo este comentário : "Essa questão é simples, basta lembrar dos princípios do protocólo 2PL “para toda transação Tx, todas as operações de bloqueio de dados feitas por Tx precedem a primeira operação de desbloqueio feita por Tx” Como essas transações não respeitam o 2PL, não são serializáveis e consequentemente não podem ser executadas de forma concorrente."
 
 Para ser serializáveis então a transação T1, por exemplo,  teria que ter os 3 bloqueios escalonados logo no início. Seria isso?
 
 	Na tabela DEPARTAMENTO, bloqueia a linha N em modo compartilhado; 
 Na tabela DEPARTAMENTO, lê a coluna DESPESA da linha N;
 Na tabela DEPARTAMENTO, desbloqueia a linha N;
 Na tabela PROJETO, bloqueia a linha M em modo compartilhado;
 Na tabela PROJETO, lê a coluna VERBA da linha M;
 Na tabela PROJETO, desbloqueia a linha M;
 Na tabela PROJETO, bloqueia a linha M em modo exclusivo;
 Na tabela PROJETO, escreve a coluna VERBA da linha M com o valor VERBA + DESPESA;
 Na tabela PROJETO, desbloqueia a linha M;
 
- 
                                A questão trata de controle de concorrência.
 O protocolo 2FL (two-phase locking) - lock em duas fases, é uma das modalidades de protocolo para controle de concorrência por bloqueio (outros: binário e compatilhado). Este protocolo é definido por ter uma fase de expansão, onde ocorrem todos os bloqueios e uma fase de encolhimento onde ocorrem todos os desbloqueio. Durante a primeira fase não podem ser feitos desbloqueios, pois este representaria o início da segunda fase.
 Segundo esta característica do 2FL, as duas transações executam sequencialmente lock(x,s), leitura/escrita), unlock(). O que fere a regra do 2FL, assim os itens "b", "d", e "e" estão incorretos.
 A serialização refere-se a característica de duas transações que acessam os mesmos dados e geram o mesmo estado final no banco, sendo necessário garantir que os acesso se dêem de forma intercalada e gerem estados inconsistentes dos dados. As duas transações tratadas na questão, acessam as duas mesmas tabelas, contudo as operações de escrita e leitura são invertidas, tendo como resultado estados distintos no banco. Assim, não são serializáveis e não podem ser exeutadas concorrententemente,  sendo correto o item "a".
 Por não serem serializáveis e não podendo ser executadas concorrentemente não há como ser verdade o item "c".
- 
                                b), d) e e) estão erradas de cara, porque as transações não obedecem ao bloqueio em duas fases. Para isso acontecer, deveria haver uma fase de expansão (bloqueios) e outra fase de encolhimento (desbloqueios). Ou seja: não poderia haver novos bloqueios depois que o primeiro desbloqueio fosse relaizado.
 
 c) está errada, pois afirma que as transações podem entrar em deadlock. Isto não é possível pois cada transação só ocupa um objeto por vez. Não fica com um objeto bloqueado e esperando liberação de um segundo objeto, o que caracterizaria um deadlock.
 
 Resta letra a), que é a alternativa correta mas é bem trabalhoso chegar a esta conclusão na hora da prova. Acho que por eliminação sai mais fácil mesmo.
- 
                                Soh complementando o comentário do Redusa, de acordo com Navathe, 6a Ed. pg 527:
 
 cada T em um Schedule segue 2PL ---> Schedule é SERIALIZAVEL.
 
 Na Lógica Proposicional, teríamos:
 
 2PL -> SERIALIZAVEL (i)
 
 Assim, afirmar q:
 
 ~(2PL) ---> ~(SERIALIZAVEL)          ESTÁ ERRADO!!!
 
 2PL eh UMA  condição suficiente, mas não a única. Existe por exemplo a condição mais conhecida e simples do Grafo de Conflitos (adaptação minha de Navathe, 6a Ed. pg 517):
 
 "Suponha um Grafo com cada T sendo NOH e cada ARESTA DIRECIONADA sendo um par de operações em conflito (par de operacoes q obedecem: (1) sao d Ts diferentes (2) acessam o mesmo item X (3) pelo menos 1 das 2 operacoes é WRITE), sendo a origem da seta na transação q tem a 1a operação no tempo. Assim, temos que:
 NAO EXISTE CICLO ---->> SERIALIZAVEL"
 
 Entao, temos q:
 2PL           --> SERIALIZAVEL (i)
 ~(CICLO) --> SERIALIZAVEL (ii)
 
 Que, para termos de concursos, sao virtualmente as formas de se inferir serializabilidade.
 
 Se analisarmos a questão, veremos que há um CICLO no Grafo de Conflitos. Assim, temos:
 ~(2PL) E (CICLO)
 
 que, por Lógica Proposicional + i + ii :
 ~(2PL) E (CICLO))  ==  ~(2PL) E ~(~(CICLO)) --->  ~(SERIALIZAVEL)
 
 Assim, só restariam "a" e "c". Porém, não há deadlock pq, por definição de deadlock, para este existir, o sujeito tem q possuir previamente um bloqueio para um item e solicitar um bloqueio para outro. Como na questão não acontece esse tipo de coisa (sempre dps d um LOCK, existe um UNLOCK).
 
 Portanto, temos q o gabarito é "a"
 
- 
                                O escalonamento é serializável se possuir ALGUMA escala em que o resultado seja igual ao escalonamento serial (uma executada após a outra). Como as duas transações mexem nos mesmos dados, porém em ordem inversa, as duas transações jamais podem ser serializáveis.
 Letra A!
- 
                                Para mim a resposta correta seria a letra - C, pois se esta duas transações forem executadas concorrentemente, realmente poderia dar deadlock. A letra A esta errada, pois o 2PL prova que o escalonamento é serializável com base na equivalencia de conflito, mas caso não seja 2PL não implica que o escalonamento é não serializável.  Assim, afirmar q:
 
 ~(2PL) ---> ~(SERIALIZAVEL)  ESTÁ ERRADO!!!
 
 
- 
                                Na letra A fala que não pode ser usado concorrentemente. Já que não ocorre deadlock, então porque não podem ser usadas concorrentemente? Também acredito que a mais correta é a letra C