Os aplicativos podem iniciar e terminar transações através da interface Session. A interface Session também fornece acesso ao aplicativo com base nas interfaces ObjectMap e JavaMap.
Cada instância de ObjectMap ou de JavaMap está diretamente ligada a um objeto de Sessão específico. Cada encadeamento que desejar acesso a um eXtreme Scale deve primeiro obter uma Sessão do objeto ObjectGrid. Uma instância de Sessão não pode ser compartilhada simultaneamente entre encadeamentos. O WebSphere eXtreme Scale não usa qualquer armazenamento local do encadeamento, mas restrições de plataforma podem limitar a oportunidade de passar uma Sessão de um encadeamento para outro.
Método Get
Um aplicativo obtém uma instância da Sessão a partir de um objeto ObjectGrid usando o método ObjectGrid.getSession. O exemplo a seguir demonstra como obter uma instância de Session:
ObjectGrid objectGrid = ...; Session sess = objectGrid.getSession();
Após uma Sessão ter sido obtida, o encadeamento mantém uma referência à sessão para sua própria utilização. Chamar o método getSession várias vezes sempre retorna, cada vez, um novo objeto de Sessão.
Métodos de Transações e Sessão
Uma Sessão pode ser utilizada para iniciar, confirmar ou efetuar rollback de transações. As operações em BackingMaps que utilizam ObjectMaps e JavaMaps são desempenhadas de maneira mais eficiente em uma transação de Sessão. Quando uma transação é iniciada, as alterações em um ou mais BackingMaps nesse escopo de transação são armazenadas em um cache de transações especiais até que a transação seja confirmada. Quando uma transação é confirmada, as alterações pendentes são aplicadas aos BackingMaps e Loaders e se tornam visíveis a outros clientes desse ObjectGrid.
O WebSphere eXtreme Scale também suporta a habilidade de automaticamente consolidar transações, também conhecida como auto-consolidação. Se quaisquer operações do ObjectMap forem desempenhadas fora do contexto de uma transação ativa, uma transação implícita será iniciada antes da operação e a transação será automaticamente confirmada antes de retornar o controle ao aplicativo.
Session session = objectGrid.getSession();
ObjectMap objectMap = session.getMap("someMap");
session.begin();
objectMap.insert("key1", "value1");
objectMap.insert("key2", "value2");
session.commit();
objectMap.insert("key3", "value3"); // auto−commit
Método Session.flush
O método Session.flush faz sentido apenas quando um Loader está associado a um BackingMap. O método flush chama o Loader com o conjunto atual de alterações no cache de transações. O Loader aplica as alterações ao backend. Estas alterações não são confirmadas quando o flush é chamado. Se uma transação de Sessão for confirmada após uma chamada de flush, apenas as atualizações que ocorrem após a chamada do flush serão aplicadas ao Loader. Se uma transação de Sessão receber rollback após uma chamada de flush, as alterações limpas serão descartadas com todas as demais alterações pendentes na transação. Utilize o método Flush com moderação, pois ele limita a oportunidade de operações de batch em um Loader. A seguir está um exemplo do uso do método Session.flush:
Session session = objectGrid.getSession();
session.begin();
// fazer algumas alterações
...
session.flush(); // enviar estas alterações para o Loader, mas ainda não confirmar
// fazer mais algumas alterações
...
session.commit();
Método NoWriteThrough
Alguns mapas são suportados por um Loader, que fornece armazenamento persistente aos dados no mapa. Algumas vezes, é útil consolidar dados apenas no mapa do eXtreme Scale e não executar o push de dados para fora do Utilitário de Carga. A interface Session fornece o método beginNoWriteThough para esta finalidade. O método beginNoWriteThrough inicia uma transação como o método begin. Com o método beginNoWriteThrough, quando a transação é confirmada, os dados são confirmados apenas para o mapa na memória e não são confirmados para o armazenamento persistente que é fornecido pelo Loader. Este método é muito útil ao desempenhar o pré-carregamento de dados no mapa.
Ao utilizar uma instância do ObjectGrid distribuído, o método beginNoWriteThrough é útil para fazer alterações apenas no near cache, sem modificar o far cache no servidor. Se os dados forem considerados stale no near cache, a utilização do método beginNoWriteThrough pode permitir que entradas sejam invalidadas no near cache sem invalidá-las também no servidor.
A interface Session também fornece o método isWriteThroughEnabled para determinar qual o tipo de transação está ativo no momento.
Session session = objectGrid.getSession();
session.beginNoWriteThrough();
// fazer algumas alterações...
session.commit(); // estas alterações não serão enviadas ao Loader
Obter o Método de Objeto TxID
O objeto TxID é um objeto opaco que identifica a transação ativa. Utilize o objeto TxID para as seguintes finalidades:
Consulte o plug-in TransactionCallback e Loaders para obter informações adicionais sobre o recurso de slot do Objeto.
Método de monitoramento de desempenho
Se estiver usando o eXtreme Scale dentro do WebSphere Application Server, pode ser necessário reiniciar o tipo de transação para monitoramento de desempenho. É possível configurar o tipo de transação com o método setTransactionType. Consulte Monitoramento do Desempenho do ObjectGrid com a PMI (Performance Monitoring Infrastructure) do WebSphere Application Server para obter informações adicionais sobre o método setTransactionType.
Processar um Método LogSequence Completo
O WebSphere eXtreme Scale pode propagar conjuntos de alterações de mapas para listeners de ObjectGrid como um meio de distribuição de mapas de um Java Virtual Machine para outro. Para facilitar o processamento pelo listener de LogSequences recebidos, a interface Session fornece o método processLogSequence. Este método examina cada LogElement no LogSequence e desempenha uma operação apropriada, por exemplo, inserção, atualização, invalidação e outros, no BackingMap identificado pelo MapName LogSequence. Uma Sessão do ObjectGrid deve estar disponível antes de o método processLogSequence ser chamado. O aplicativo também é responsável por emitir as chamadas de confirmação ou de rollback apropriadas para concluir a Sessão. O processamento da confirmação automática não está disponível para esta chamada de método. O processamento normal pelo ObjectGridEventListener receptor na JVM remota seria iniciar uma Sessão utilizando o método beginNoWriteThrough, que evita a propagação sem fim de alterações, seguido de uma chamada para este método processLogSequence e, então, consolidando ou retrocedendo a transação.
// Utilizar o objeto de Sessão transmitido durante
//ObjectGridEventListener.initialization...
session.beginNoWriteThrough();
// processar o LogSequence recebido
try {
session.processLogSequence(receivedLogSequence);
} catch(Exception e) {
session.rollback(); throw e;
}
// confirmar as alterações
session.commit();
Método markRollbackOnly
Este método é utilizado para marcar a transação atual como "apenas rollback". Marcar uma transação como "apenas rollback" assegura que, mesmo que o método commit seja chamado pelo aplicativo, a transação receba rollback. Este método geralmente é utilizado pelo próprio ObjectGrid ou pelo aplicativo quando ele sabe que pode ocorrer danos nos dados se a transação tiver permissão para ser confirmada. Após este método ser chamado, o objeto Throwable que é passado a este método é encadeado na exceção com.ibm.websphere.objectgrid.TransactionException que resulta do método commit se for chamado em uma Sessão que foi anteriormente marcada como "apenas retrocesso". As chamadas subsequentes para este método para uma transação que já está marcada como "apenas rollback" serão ignoradas. Ou seja, apenas a primeira chamada que transmite uma referência Throwable não nula é utilizada. Quando a transação marcada estiver concluída, a marca "apenas rollback" será removida para que a próxima transação iniciada pela Sessão possa ser confirmada.
Método isMarkedRollbackOnly
Retorna se a Sessão está marcada como "apenas rollback". O true booleano será retornado por este método apenas se um método markRollbackOnly tiver sido chamado anteriormente nesta Sessão e a transação iniciada pela Sessão ainda estiver ativa.
Método setTransactionTimeout
Configure o tempo limite de transação para a próxima transação iniciada por esta Sessão como um número de segundos especificado. Este método não afeta o tempo limite da transação de nenhuma transação iniciada anteriormente por esta Sessão. Afeta apenas as transações iniciadas após este método ter sido chamado. Se este método nunca for chamado, o valor de tempo limite transmitido para o método setTxTimeout do método com.ibm.websphere.objectgrid.ObjectGrid será utilizado.
Método getTransactionTimeout
Este método retorna o valor de tempo limite da transação em segundos. O último valor que foi transmitido como o valor de tempo limite para o método setTransactionTimeout é retornado por este método. Se o método setTransactionTimeout nunca for chamado, o valor de tempo limite transmitido para o método setTxTimeout do método com.ibm.websphere.objectgrid.ObjectGrid será utilizado.
transactionTimedOut
Este método retorna true booleano se a transação atual iniciada por esta Sessão tiver seu tempo limite excedido.
Método isFlushing
Este método retorna true booleano apenas se todas as alterações de transação forem esvaziadas do plug-in do Utilitário de Carga como resultado do método flush da interface Session que está sendo chamada. Um plug-in do Utilitário de Carga pode achar este método útil quando ele precisar saber porquê seu método batchUpdate foi chamado.
Método isCommitting
Este método retorna true booleano apenas se todas as alterações de transação forem confirmadas como resultado do método commit da interface Session que está sendo chamada. Um plug-in do Loader pode achar este método útil quando precisar saber por que seu método batchUpdate foi chamado.
Método setRequestRetryTimeout
Este método define o valor de tempo limite de nova tentativa para a sessão em milissegundos. Se o cliente definir um tempo limite de nova tentativa de solicitação, a configuração da sessão prevalece em relação ao valor do cliente.
Método getRequestRetryTimeout
Este método obtém a configuração atual de tempo limite de nova tentativa na sessão. Uma valor de -1 indica que o tempo limite não está configurado. Um valor de 0 indica que ele está no modo fail-fast. Um valor maior que 0 indica a configuração de tempo limite em milissegundos.