Sistemas de objectos persistentes são sistemas que suportam criação e manipulação de objectos de uma maneira uniforme, sem que seja importante o tempo durante o qual estes existem. Esta aproximação contrasta com a de sistemas convencionais, onde os objectos temporários são criados e manipulados por um determinado mecanismo (tipicamente estruturas de dados de uma linguagem de programação), e os objectos persistentes são mantidos utilizando um mecanismo diferente (e.g. ficheiros ou bases de dados). Da uniformização do tratamento resultam sistemas de menor dimensão e potencialmente mais eficientes que os convencionais.
O modelo que se vai usar para a persistência é semelhante ao que foi
utilizado no sistema IK [Sousa et al., 1994], isto é, persistência
ortogonal [Atkinson et al., 1983]. Pretende-se seguir, tão fielmente quanto
possível, o modelo original. Assim, têm-se as características de um
sistema de persistência ortogonal: independência da
persistência em relação a outras particularidades dos objectos,
tais como a forma de criação ou manipulação; ortogonalidade de
tipos, ou seja, qualquer objecto pode ser persistente,
independentemente do seu tipo
; o mecanismo para distinguir objectos persistentes
de não persistentes é independente do sistema de tipos e do modelo
computacional ( identificação da persistência).
Tal como no modelo original, tem-se uniformidade de acesso aos objectos. Esta uniformidade consegue-se, uma vez mais, através da utilização de envelopes. Estes permitem que um objecto persistente continue a ser tratado como se fosse um objecto normal.
Um objecto que se pretende tornar persistente é criado como qualquer outro. Qualquer objecto que possua um envelope pode ser tornado persistente, qualquer que seja o seu estado, e.g. distribuído, ou localização. Pode assim um contexto pedir a outro que torne um dos seus objectos persistentes ou mesmo que reenvie o pedido a um terceiro. As duas situações são ilustradas na figura 5.7, muito sumariamente e sem preocupações com aspectos que se tomarão em conta mais adiante (e.g. transparência).
Figure: Dois exemplos de persistência.
Na primeira parte da figura, uma entidade do programa envia um pedido, do tipo StoreObject, ao gestor de persistência (PM) para que torne o objecto A persistente. O objecto, sendo residente no contexto em causa, é armazenado. A este nível de descrição não são importantes pormenores de funcionamento do mecanismo. Na segunda parte da figura tem-se uma situação análoga, mas o objecto real não existe no mesmo contexto que a entidade X (entidade genérica do programa). Neste caso, o que é passado ao PM do contexto I é uma referência para um objecto remoto. Isto vai ter como consequência o envio de um comando ao objecto real para que se torne persistente. Sendo esta uma acção que só pode ser realizada no contexto onde o objecto real reside, será redireccionada, por tantos contextos quantos os necessários, até que se atinja o destino (na figura, o contexto II). A acção decorre então como na primeira parte, tomando A o papel da entidade X.
A persistência, segundo o modelo apresentado nesta secção está
dividida em duas partes distintas, a mudança de estado, partindo de um
objecto não persistente, e sua subsequente salvaguarda, e o
carregamento de um objecto persistente a partir de um repositório. A
natureza deste repositório pode variar, não sendo, contudo importante
nesta fase. Deverá ser visto apenas como lugar de origem do objecto e
não como tendo características especiais, tais como, por exemplo,
memória estável. Antes das operações de manipulação
de alto nível é descrita a estrutura de armazenamento dos objectos.
Nas discussões que se seguem, assume-se que todo o objecto está em memória, excepto quando algo for dito em contrário.