Manipulando Atualizações Write-Behind Falhas

Como a transação do WebSphere eXtreme Scale termina antes de a transação de backend iniciar, é possível que ocorra um falso sucesso da transação.

Se você tentar inserir uma entrada em uma transação do eXtreme Scale que não exista no mapa de apoio mas existe no banco de dados backend, causando uma chave duplicada, a transação do eXtreme Scale será bem-sucedida. Entretanto, a transação na qual o encadeamento write-behind insere o objeto no banco de dados backend falha com uma exceção de chave duplicada.

Manipulando Atualizações write-behind com Falha: Lado do Cliente

Uma atualização deste tipo, ou qualquer outra atualização de backend falha, é uma atualização write-behind falha. Atualizações write-behind falhas são armazenadas em um mapa de atualização write-behind falho. Este mapa funciona como uma fila de eventos para atualizações falhas. A chave da atualização é um objeto Integer exclusivo e o valor é uma instância do FailedUpdateElement. O mapa de atualização write-behind com falha é configurado com um evictor, que despeja os registros uma hora depois de terem sido inseridos. Assim, os registros de atualização com falha serão perdidos se eles não forem recuperados dentro de 1 hora.

A API do ObjectMap pode ser utilizada para recuperar as entradas do mapa de atualização write-behind falho. O nome do mapa de atualização write-behind com falha é: IBM_WB_FAILED_UPDATES_<map name>. Consulte a documentação da API do WriteBehindLoaderConstants para os nomes de prefixo de cada um dos mapas do sistema write-behind. A seguir há um exemplo.

processo com falha - código de exemplo
ObjectMap failedMap = session.getMap(
    WriteBehindLoaderConstants.WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX + "Employee");
Object key = null;

session.begin();
while(key = failedMap.getNextKey(ObjectMap.QUEUE_TIMEOUT_NONE)) {
    FailedUpdateElement element = (FailedUpdateElement) failedMap .get(key);
    Throwable throwable = element.getThrowable();
    Object failedKey = element.getKey();
    Object failedValue = element.getAfterImage();
    failedMap .remove(key);
    // Faça algo interessante com a chave, o valor ou a exceção.

}
session.commit();

Uma chamada de método getNextKey funciona com uma partição específica para cada transação eXtreme Scale. Em um ambiente distribuído, para obter chaves de todas as partições, você deve iniciar diversas transações, como mostrado no exemplo a seguir :

obtendo chaves de todas as partições - código de exemplo
ObjectMap failedMap = session.getMap(
    WriteBehindLoaderConstants.WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX + "Employee");
while (true) {
    session.begin();
    Object key = null; 
    while(( key = failedMap.getNextKey(5000) )!= null ) {
        FailedUpdateElement element = (FailedUpdateElement) failedMap .get(key);
    Throwable throwable = element.getThrowable();
        Object failedKey = element.getKey();
        Object failedValue = element.getAfterImage();
        failedMap .remove(key);
        // Faça algo interessante com a chave, o valor ou a exceção.

    }
    Session.commit();
}
Nota: O mapa de atualização com falha fornece uma maneira de monitorar o funcionamento do aplicativo. Se um sistema produzir muitos registros no mapa de atualização com falha, significa que é necessário revisar o aplicativo ou a arquitetura para usar o suporte write-behind. É possível usar o comando xscmd -showMapSizes para ver o tamanho da entrada do mapa de atualização com falha.

Manipulando atualizações write-behind com Falha: Listener do Shard

É importante detectar e registrar quando uma transação write-behind falha. Todo aplicativo utilizando write-behind precisa implementar um watcher para manipular atualizações write-behind falhas. Isto evita potencialmente ficar sem memória já os registros no Mapa de atualização inválido não são despejados porque o aplicativo é esperado para manipulá-los.

O código a seguir mostra como conectar tal watcher, ou "dumper ", que deve ser incluído no descritor XML do ObjectGrid como no fragmento.

	<objectGrid name="Grid">
		<bean id="ObjectGridEventListener" className="utils.WriteBehindDumper"/>

É possível visualizar o bean ObjectGridEventListener que foi incluído, que é o watcher write-behind referido acima. O watcher interage nos Mapas para todos os shards principais em um JVM procurando por aqueles com write-behind ativado. Se ele localizar um, então, ele tenta registrar até 100 atualizações inválidas. Ele continua observando um shard principal até que o shard seja movido para um JVM diferente. Todos os aplicativos que usam write-behind devem usar um watcher semelhante a este. Caso contrário, o Java Virtual Machines fica sem memória porque este mapa de erro nunca é despejado.

Consulte o Exemplo: Gravando uma Classe Dumper no Modo write-behind para obter informações adicionais.