Isolamento de transação

Para transações, é possível configurar cada configuração de mapa de apoio com uma das três estratégias de bloqueio: pessimistic, optimistic ou none. Quando você usa os bloqueios pessimistic e optimistic, o eXtreme Scale usa bloqueios compartilhado(S), atualizável (U) e exclusivo (X) para manter a consistência. Este comportamento de bloqueio é mais perceptível quando o bloqueio pessimistic é usado, pois os bloqueios optimistic não são mantidos. É possível usar um dos três níveis de isolamento de transação para ajustar as semânticas de bloqueio que o eXtreme Scale usa para manter a consistência em cada mapa de cache: repeatable read, read committed e read uncommitted.

Visão Geral de Isolamento da Transação

O isolamento de transação define como as alterações que são feitas por uma operação se tornam visíveis a outras operações concorrentes.

O WebSphere eXtreme Scale suporta três níveis de isolamento de transação com os quais é possível ajustar adicionalmente as semânticas de bloqueio que o eXtreme Scale usa para manter a consistência em cada mapa do cache: repeatable read, read committed e read uncommitted. O nível de isolamento de transação é configurado na interface Sessão usando o método setTransactionIsolation. O isolamento de transação pode ser alterado a qualquer momento durante a duração da sessão, se uma transação não estiver atualmente em andamento.

O produto força várias semânticas de isolamento de transação ajustando a forma na qual os bloqueios compartilhados (S) são solicitados e mantidos. O isolamento de transação não tem efeito nos mapas configurado para utilizar as estratégias de bloqueio optimistic ou none ou quando bloqueios atualizáveis (U) são necessários.

Leitura Repetível com Bloqueio Pessimistic

O nível de isolamento de transação repeatable read é o padrão. Este nível de isolamento evita leituras sujas e leituras não repetitivas, mas não evita leituras fantasmas. Uma leitura suja é uma operação de leitura que ocorre nos dados que foram modificados por uma transação mas não foi consolidada. Uma leitura não repetitiva pode ocorrer quando os bloqueios de leitura não são adquiridos na execução de uma operação de leitura. Uma leitura fantasma pode ocorrer quando duas operações de leitura idênticas são executadas, mas dois conjuntos diferentes de resultados são retornados porque uma atualização ocorreu nos dados entre as operações de leitura. O produto atinge uma leitura repetitiva se mantendo em qualquer bloqueio S até que a transação que possui o bloqueio seja concluída. Como um bloqueio X não é concedido até que todos os bloqueios S sejam liberados, todas as transações contendo o bloqueio S são garantidas para visualizar o mesmo valor quando lidas novamente.
map = session.getMap("Order");
session.setTransactionIsolation(Session.TRANSACTION_REPEATABLE_READ);
session.begin();

// An S lock is requested and held and the value is copied into 
// the transactional cache.
Order order = (Order) map.get("100");
// The entry is evicted from the transactional cache.
map.invalidate("100", false);

// The same value is requested again.  It already holds the 
// lock, so the same value is retrieved and copied into the 
// transactional cache.
Order order2 (Order) = map.get("100");

// All locks are released after the transaction is synchronized
// with cache map.
session.commit();
As leituras fantasmas são possíveis quando você usa consultas ou índices pois os bloqueios não são adquiridos para intervalos de dados, somente para as entradas de cache que correspondem ao índice ou critérios de busca. Por exemplo:
session1.setTransactionIsolation(Session.TRANSACTION_REPEATABLE_READ);
session1.begin();

// A query is run which selects a range of values.
ObjectQuery query = session1.createObjectQuery
    ("SELECT o FROM Order o WHERE o.itemName='Widget'");

// In this case, only one order matches the query filter.  
// The order has a key of "100".
// The query engine automatically acquires an S lock for Order "100".
Iterator result = query.getResultIterator();

// A second transaction inserts an order that also matches the query.
Map orderMap = session2.getMap("Order");
orderMap.insert("101", new Order("101", "Widget"));

// When the query runs again in the current transaction, the 
// new order is visible and will return both Orders "100" and "101".
result = query.getResultIterator();

// All locks are released after the transaction is synchronized
// with cache map.
session.commit();

Leitura com Commit com Bloqueio Pessimistic

O nível de isolamento de transação consolidado da leitura pode ser usado com o eXtreme Scale, o que evita leituras sujas, mas não evita leituras não repetitivas ou leituras fantasmas, assim o eXtreme Scale continua a usar bloqueios S para ler dados a partir do mapa de cache, mas libera imediatamente os bloqueios.
map1 = session1.getMap("Order");
session1.setTransactionIsolation(Session.TRANSACTION_READ_COMMITTED);
session1.begin();

// An S lock is requested but immediately released and
//the value is copied into the transactional cache.

Order order = (Order) map1.get("100");

// The entry is evicted from the transactional cache.
map1.invalidate("100", false);

// A second transaction updates the same order.
// It acquires a U lock, updates the value, and commits.
// The ObjectGrid successfully acquires the X lock during
// commit since the first transaction is using read
// committed isolation.

Map orderMap2 = session2.getMap("Order");
session2.begin();
order2 = (Order) orderMap2.getForUpdate("100");
order2.quantity=2;
orderMap2.update("100", order2);
session2.commit();

// The same value is requested again.  This time, they
// want to update the value, but it now reflects
// the new value
Order order1Copy (Order) = map1.getForUpdate("100");

Leitura não Consolidada com Bloqueio Pessimistic

O nível de isolamento de transação não consolidado de leitura pode ser usado com o eXtreme Scale, o que é um nível que permite leituras sujas, leituras não repetitivas e leituras fantasmas.