O processo de localização visa descobrir onde se encontra o grafo de correspondente a um dado objecto e se alguma das suas raízes se encontra carregada noutro contexto. Se for este o caso, a única possibilidade de acesso é através de distribuição. Neste caso o objecto, além de persistente, é implicitamente distribuído. Num sistema com suporte para replicação, poder-se-ia carregar uma réplica do objecto.
O repositório de objectos persistentes é controlado por um servidor que é conhecido por todos os gestores de persistência, que são eles próprios objectos distribuídos.
Quando um destes gestores contacta o servidor para carregar um objecto pode acontecer uma de duas coisas: o objecto requisitado ainda não foi carregado por nenhum contexto, ou já o foi.
No primeiro caso, o identificador de distribuição do gestor de persistência que fez o pedido de carregamento fica registado no servidor do repositório e os blocos de dados do grafo persistente, correspondentes ao identificador de objecto pedido, são passados ao contexto.
No segundo caso, o servidor do repositório possui o identificador de distribuição do gestor de persistência que carregou o objecto. Este identificador é enviado ao contexto que fez o pedido. Não são enviados dados sobre nenhum objecto persistente. Cabe ao gestor que recebe este identificador a decisão de contactar o gestor dono do objecto. Este deverá exportar o objecto para que possa ser posteriormente importado.
O gestor do contexto exportador guarda numa tabela a identificação do gestor de persistência correspondente ao contexto que importou o objecto.
Considere-se o exemplo da figura 5.13. Nela, existem dois objectos persistentes: NOME1, ao qual está associado o identificador 3, e NOME2, ao qual está associado o identificador 4. O contexto 1 carrega NOME1 e o contexto 2 carrega NOME2. Por hipótese o agrupamento do segundo contexto contém uma referência para um objecto do agrupamento carregado pelo primeiro contexto, 3:26. Um acesso a este objecto vai detectar a sua falta e provocar uma tentativa de carregamento que vai ser frustrada pelo facto de 3 já estar carregado no contexto 1. O gestor do contexto 2 contacta o de 1 para que seja estabelecida uma ligação remota entre os dois contextos. Note-se que 3:26 é exportado por CTX1 antes do retorno de VII e importado por CTX2 imediatamente após o retorno de VII.
Figure: Concorrência no acesso ao repositório.
Depois do carregamento de um bloco do repositório ele deve ser convertido no grafo de objectos que pode ser utilizado pela aplicação, sendo criados os envelopes e cartas correspondentes à informação de tipos e de referências relativas à informação contida nos cabeçalhos do bloco. Parte-se do princípio que os tipos conhecidos no contexto são os apropriados para o contexto que está a ser carregado.