Controle de Simultaneidade

O controle de simultaneidade é o gerenciamento de contenção para recursos de dados. Um esquema de controle de simultaneidade é considerado pessimista quando ele bloqueia um determinado recurso antecipadamente na transação de acesso a dados e não o libera até que a transação seja fechada. Um esquema de controle de simultaneidade é considerado otimista quando os bloqueios são adquiridos e liberados em um curto período de tempo no término de uma transação.

O objetivo da simultaneidade otimista é diminuir o tempo em que um determinado recurso fica indisponível para uso de outras transações. Isto é especialmente importante com transações demoradas, as quais sob um esquema pessimista bloqueariam um recurso por períodos de tempo inaceitavelmente longos.

Em um esquema otimista, os bloqueios são obtidos imediatamente antes de uma operação de leitura e liberados imediatamente após. As travas de atualização são obtidas imediatamente antes de uma operação de atualização e mantidas até o final da transação.

Para ativar a simultaneidade otimista, esse produto utiliza um esquema de atualização super qualificada para testar se a origem de dados subjacente foi atualizada por outra transação desde o início da transação atual. Com esse esquema, as colunas marcadas para atualização e seus valores originais são adicionados explicitamente por meio de uma cláusula WHERE na instrução UPDATE de modo que a instrução falhe se os valores de colunas subjacentes tiverem sido alterados. Como resultado, esse esquema pode fornecer controle de simultaneidade no nível da coluna; os esquemas pessimistas podem controlar a simultaneidade somente no nível da linha.

Os esquemas otimistas, em geral, executam esse tipo de teste somente no final de uma transação. Se as colunas subjacentes não tiverem sido atualizadas desde o início da transação, será efetuado commit das atualizações pendentes a campos de persistência gerenciada por contêiner e as travas serão liberadas. Se não for possível adquirir travas ou se alguma outra travar atualizou as colunas desde o início da transação atual, é efetuado rollback da transação; todo o trabalho executado dentro da transação é perdido.

Os esquemas de simultaneidade pessimista e otimista exigem níveis de isolamento de transação diferentes. Os beans corporativos que participam na mesma transação e exigem esquemas de controle de simultaneidade diferentes não podem operar na mesma conexão de dados subjacente.

boas práticas: Se o uso da simultaneidade otimista depende do tipo de transação. Transações com uma penalidade elevada por falha podem ser melhor gerenciadas com um esquema pessimista. Uma transação de penalidade alta é aquela cuja recuperação é arriscada ou que exige muitos recursos. Para transações com penalidade baixa, frequentemente vale a pena correr o risco da falha para ganhar eficiência por meio do uso de um esquema otimista. Em geral, a simultaneidade otimista é mais eficiente quando se espera que as colisões de atualização não sejam frequentes; a simultaneidade pessimista é mais eficiente quando se espera que colisões de atualização ocorram com frequência.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_cncr
Nome do arquivo: cejb_cncr.html