Após um aplicativo fazer uma referência a uma instância ObjectGrid ou uma conexão do cliente com uma grade de dados remota, é possível acessar e interagir com os dados em sua grade de dados. Com a API do ObjectGridManager, é possível criar uma instância local ou estabelecer uma conexão do cliente com uma instância distribuída. Para criar uma instância local, use um dos métodos createObjectGrid. Para estabelecer uma conexão do cliente com uma grade de dados remota, use o método getObjectGrid.
Um encadeamento em um aplicativo precisa de sua própria Sessão. Quando você desejar que seu aplicativo use o ObjectGrid em um encadeamento, chame um dos métodos getSession para obter uma Sessão. Após o aplicativo ser concluído com a Sessão, chame o método Session.close(). Esse método fecha a sessão retornando-a para o conjunto e liberando seus recursos. Fechar a sessão é opcional, mas melhora o desempenho das chamadas subsequentes para o método getSession(). Se o aplicativo estiver usando uma estrutura de injeção independente como Spring, é possível injetar uma Sessão em um bean de aplicativo quando necessário.
Após obter uma Sessão, o aplicativo pode acessar dados armazenados em mapas no ObjectGrid. Se o ObjectGrid usar entidades, é possível usar a API de EntityManager, que pode ser obtida com o método Session.getEntityManager. Porque ele está mais próxima das especificações Java, a interface EntityManager é mais simples que a API baseada em mapa. Porém, a API de EntityManager transporta um gasto adicional de desempenho porque controla as alterações em objetos. A API baseada em mapa é obtida usando o método Session.getMap.
O WebSphere eXtreme Scale usa transações. Quando um aplicativo interage com Session, ele deve estar no contexto de uma transação. Uma transação é iniciada e consolidade ou retrocedida usando os métodos Session.begin, Session.commit e Session.rollback no objeto Sessão. Os aplicativos também podem funcionar no modo auto-commit, no qual Session inicia automaticamente e executa o commit de uma transação sempre que o aplicativo interagem com Mapas. Entretanto, o modo de auto-consolidação é mais lento.
É possível customizar o quanto é necessário o suporte a transações. Seu aplicativo pode desligar o suporte ao retrocesso e bloqueio, mas ele faz isso com prejuízo para o aplicativo. O aplicativo deve manipular a falta desses recursos.
Por exemplo, um aplicativo pode desligar o bloqueio configurando a estratégia de bloqueio de BackingMap para que seja NONE. Esta estratégia é rápida, mas transações simultâneas agora podem modificar os mesmos dados sem nenhuma proteção uma da outra. O aplicativo é responsável por todos os bloqueios e consistências de dados quando NONE é utilizado.
Um aplicativo também pode alterar a maneira como os objetos são copiados quando acessados pela transação. O aplicativo pode especificar como os objetos são copiados com o método ObjectMap.setCopyMode. Com este método, é possível desligar CopyMode. Desligar CopyMode normalmente é usado para transações somente de leitura se diferentes valores podem ser retornados para o mesmo objeto dentro de uma transação. Valores diferentes podem ser retornados para o mesmo objeto dentro de uma transação.
Por exemplo, se a transação chamou o método ObjectMap.get para o objeto em T1, ela obtém o valor naquele ponto no tempo. Se ela chamar o método get novamente dentro dessa transação em um tempo posterior T2, outro encadeamento pode ter alterado o valor. Em razão do valor ter sido alterado por outro encadeamento, o aplicativo vê um valor diferente. Se o aplicativo modifica um objeto recuperado usando um valor de CopyMode NONE, ele está alterando a cópia consolidada desse objeto diretamente. A recuperação da transação não faz sentido neste modo. Você está alterando a única cópia no ObjectGrid. Apesar do uso de CopyMode NONE ser rápido, esteja ciente de suas consequências. Um aplicativo que usa o CopyMode NONE nunca deve retroceder a transação. Se o aplicativo retroceder a transação, os índices não são atualizados com as alterações e as alterações não são replicadas se a replicação estiver desativada. Os valores padrão são fáceis de usar e menos propensos a erros. Se você começar a trocar desempenho por dados menos confiáveis, o aplicativo precisará estar ciente do que está fazendo para evitar problemas indesejados.
Após obter uma sessão, é possível usar o fragmento de código a seguir para usar a API do Mapa para inserir dados.
Session session = ...;
ObjectMap personMap = session.getMap("PERSON");
session.begin();
Person p = new Person();
p.name = "John Doe";
personMap.insert(p.name, p);
session.commit();
O mesmo exemplo usando a API do EntityManager está a seguir. Esta amostra de código supõe que o objeto Pessoal é mapeado para uma Entidade.
Session session = ...;
EntityManager em = session.getEntityManager();
session.begin();
Person p = new Person();
p.name = "John Doe";
em.persist(p);
session.commit();
O padrão é projetado para obter referências aos ObjectMaps para os Mapas com os quais o encadeamento trabalha, inicia uma transação, trabalha com os dados e depois consolida a transação.
A interface ObjectMap tem as operações de Mapa comuns, como put, get e remove. Porém, use os nomes de operação mais específicos como: get, getForUpdate, insert, update e remove. Esses nomes de métodos expressam o intento mais precisamente que as APIs de Mapa tradicionais.
Também é possível usar o suporte à indexação, que é flexível.
A seguir está um exemplo para atualização de um Objeto:
session.begin();
Person p = (Person)personMap.getForUpdate("John Doe");
p.name = "John Doe";
p.age = 30;
personMap.update(p.name, p);
session.commit();
Normalmente o aplicativo usa o método getForUpdate em vez de um get simples para bloquear o registro. O método update deve ser chamado para fornecer o valor atualizado para o mapa. Se o método update não for chamado, então o mapa não é alterado. A seguir está o mesmo fragmento usando a API de EntityManager:
session.begin();
Person p = (Person)em.findForUpdate(Person.class, "John Doe");
p.age = 30;
session.commit();
A API de EntityManager é mais simples que a abordagem de Mapa. Neste caso, o eXtreme Scale localiza a Entidade e retorna um objeto gerenciado para o aplicativo. O aplicativo modifica o objeto e consolida a transação, e o eXtreme Scale controla as alterações para objetos gerenciados automaticamente no tempo de consolidação e executa as atualizações necessárias.
As transações do WebSphere eXtreme Scale podem ser atualizadas em uma partição única. As transações de um cliente podem fazer a leitura a partir de diversas partições, mas somente podem atualizar uma partição. Se um aplicativo tentar atualizar duas partições, então a transação falha e é retrocedida. Uma transação que está usando um ObjectGrid (lógica da grade) integrado não tem capacidade de roteamento e somente pode ver os dados na partição local. Esta lógica de negócios sempre pode obter uma segunda sessão que é uma sessão do cliente true para acessar outras partições. Porém, esta transação seria uma transação independente.
Se uma transação já buscou por uma Entidade, a transação é associada com a partição para essa Entidade. Quaisquer consultas que executam em uma transação que está associada com uma Entidade são roteadas para a partição associada.
Se uma consulta é executada em uma transação antes de ser associada com uma partição, você deve configurar o ID da partição a ser usado para a consulta. O ID da partição é um valor de número inteiro. A consulta é, então, roteada para essa partição.
As consultas pesquisam somente dentro de uma única partição. Porém, é possível usar as PIs do DataGrid para executar a mesma consulta em paralelo em todas as partições ou em um subconjunto de partições. Use as APIs do DataGrid para localizar uma entrada que podem estar em qualquer partição.
O serviço de dados REST permite que qualquer cliente HTTP acesse uma grade do WebSphere eXtreme Scale, além de ser compatível com WCF Data Services no Microsoft .NET Framework 3.5 SP1. Para obter informações adicionais, consulte Configurando Serviços de Dados REST.
.