Operações de Gravação

É possível controlar manualmente quando dados de sessão modificados são gravados no banco de dados ou em outra instância do WebSphere Application Server utilizando o método de sincronização na interface com.ibm.websphere.servlet.session.IBMSession. Os modos de atualização manual, de servlet de fim de serviço e de frequência de gravação baseada no tempo estão disponíveis para ajustar a frequência de gravação dos dados de sessão.

Essa interface estende a interface javax.servlet.http.HttpSession. Chamando o método sync a partir do método service de um servlet, você envia as mudanças da sessão para um local externo. Quando a atualização manual é selecionada como o modo de frequência de gravação, as alterações dos dados da sessão são gravadas em um local externo somente se o aplicativo chamar o método sync. Se o método sync não for chamado, as mudanças dos dados da sessão serão perdidas quando um objeto de sessão sair do cache do servidor. Quando o final do servlet de serviço ou baseado em tempo é o modo de frequência de gravação, as alterações dos dados da sessão são gravadas sempre que o método sync for chamado. Se o método sync não for chamado, as alterações serão gravadas no final do método service ou com base em um intervalo de tempo baseado no modo de frequência de gravação selecionado.

IBMSession iSession = (IBMSession) request.getSession();
iSession.setAttribute("name", "Bob");

//forçar gravação em armazenamento externo
iSession.sync( )

Se o banco de dados estiver desativado ou estiver tendo dificuldades de conexão durante uma atualização dos valores de sessão, o método sync sempre faz três tentativas antes de finalmente criar um erro BackedHashtable.getConnectionError. Para cada tentativa de conexão que falha, BackedHashtable.StaleConnectionException é criado e pode ser localizado no método sync. Se o banco de dados abrir durante qualquer uma dessas três tentativas, os dados de sessão na memória serão, então, colocados e consolidados no banco de dados.

No entanto, se o banco de dados ainda não estiver ativado depois de três tentativas, os dados de sessão da memória serão colocados apenas depois da próxima verificação de invalidação da sessão. A invalidação de sessão é verificada por um encadeamento separado que é disparado a cada cinco minutos. Os dados da memória são consistentes, a menos que um pedido de dados de sessão seja emitido para o servidor entre esses eventos. Por exemplo, se o pedido dos dados de sessão forem emitidos dentro de cinco minutos, os dados de sessão colocados anteriormente serão enviados.

Sessões não são recursos transacionais. Como o método sync está associado a um encadeamento separado do cliente, a exceção criada não é propagada ao cliente, que está em execução no encadeamento principal. A integridade transacional dos dados pode ser mantida por meio dos recursos, como beans corporativos.


Í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=cprs_write_ops
Nome do arquivo: cprs_write_ops.html