Existe persistência transparente?

This message was edited 2 times. Last update was at 07/07/2005 21:57:02

Pessoal, mais uma dúvida filosófica.

O que seria exatamente persistência transparente?

Pelo que eu andei mexendo e vendo, não consigo entender como é que a persistência poderia (ou não) ser transparente, porque nós sempre vamos ter que dizer pra aplicação quais objetos devem ser "mantidos". Ela não pode adivinhar nem pode achar que só porque você chamou "new", aquele objeto deve ser mantido, seria um desperdício de recursos.

Como é que fica a persistência transparente nessa? É não chamar método nenhum? É não amarrar os objetos a um "tipo" de persistência? Como é que eles vão ser reunidos?

Num sistema OO, todos os objetos não precisam ser salvos. Enquanto o objeto existir ele está acessível.

Acho que é claro para todos que isso não é viável, não existe memória para manter todos os objetos ativos ao mesmo tempo quando não estão sendo usados.

A solução é persistir em sistemas próprios (como bancos de dados). Isso é uma solução para driblar a limitação da plataforma que não atende ao paradigma.

O grande problema é que este conceito entranhado no seu sistema tira muitas das características OO dele a partir do momento que voce precisa se preocupar em quando persistir, quando salvar...
Persistencia transaprente eh ter certeza que seus objetos estao sempre a salvo sem rpecisar se preocupar com isso.

pcalcado wrote:te conceito entranhado no seu sistema tira muitas das características OO dele a partir do momento que voce precisa se preocupar em quando persistir, quando salvar...
Persistencia transaprente eh ter certeza que seus objetos estao sempre a salvo sem rpecisar se preocupar com isso.

Mas eu não teria que, no mímino, dizer quais deveriam ser persistidos?

O que eu não to entendendo é o quão transparente a persistência "pode" ser. Porque se for pra não se preocupar, eu pego um pointcut no fim do contrutor e chamo um save, ninguém viu nada acontecer, mas eu vou ter "milhares" de objetos lá onde eles deveriam ser persistidos, eu ainda tenho que escolher quais devem ir. Escolher faz parte da transparência?

Não há escolha. Por definição, todo objeto ativo em memória (não elegível para GC no caso de Java) está automaticamente persistido. Se desligar e ligar a máquina, ele tem que estar lá.

A solução pratica é passivar os objetos, colocando em discos os menos ativos (o Space4J tinha uma implementação basica disso), e é bem possível de fazer com aspectos, o problema é quão performático e eficiente isso seria.

Por isso hoje eu penso que a única maneira de se obter é implementando diretamente na JVM ou provendo ganchos para isso.

Maurício Linhares wrote:Mas eu não teria que, no mímino, dizer quais deveriam ser persistidos?

Não bastaria ter uma referência para os objetos que eles continuariam lá? Se é pra ser transparente...

Eu li em algum lugar, mas eu não encontrei mais o link para colocar aqui, sobre persistencia pela JVM (era uma implementação de JVM), inclusive já trabalhando com dezenas de gigabytes de dados/objetos, em testes.
Existe comando de checkpoint simplesmente para sincronismo e recuperação posterior.
No texto ainda dizia que apenas os objetos em "uso" eram mantidos em memória RAM.

Dharis wrote:
Eu li em algum lugar, mas eu não encontrei mais o link para colocar aqui, sobre persistencia pela JVM (era uma implementação de JVM), inclusive já trabalhando com dezenas de gigabytes de dados/objetos, em testes.
Existe comando de checkpoint simplesmente para sincronismo e recuperação posterior.

Você deve estar falando do PJama

http://research.sun.com/forest/opj.main.html

This message was edited 1 time. Last update was at 07/07/2005 14:22:47

Alguns bancos de dados OO suportam garbage collection, então teóricamente sim, você poderia salvar todos objetos sem problema. Ou no final da transação salvar somente os que tem chance de não serem coletados (referenciados pelo root set ou transitivamente duraveis)

pcalcado wrote:Não há escolha. Por definição, todo objeto ativo em memória (não elegível para GC no caso de Java) está automaticamente persistido. Se desligar e ligar a máquina, ele tem que estar lá.

louds wrote:Alguns bancos de dados OO suportam garbage collection, então teóricamente sim, você poderia salvar todos objetos sem problema. Ou no final da transação salvar somente os que tem chance de não serem coletados (referenciados pelo root set ou transitivamente duraveis)

Então vejamos, um objeto vai ficar elegível pro GC quando não houverem mais referências a ele dentro da aplicação nas threads correntes. Mas pra que alguém aponte pra ele, eu tenho que fazer uma atribuição ou chamar um método em algum lugar, pra colocar uma referência dele em um objeto que não esteja "elegível" GC.

Se chamar um método ou atribuir o objeto a algum lugar é "transparente", então usar DAOs, repositórios, AR e essas coisas é transparente?

Não.

transaperente é:

Pronto, toddy está persistido.

Se você tem que fazer algum destes:

Não é transparente.

Isso o pointcut resolve

Mas se o Orangotango não se relacionar com ninguém, ele vai ser "coletado". Ou não?

Maurício Linhares wrote:
Isso o pointcut resolve

Tá rpa surgir uma implementação eficaz que identifique quais objetos podem ser passivados e que consiga ter performance.

De qualquer jeito, este é um dos meus IIQNSP (Idéias Idiotas que Nunca Sairão do Papel)

Maurício Linhares wrote:
Mas se o Orangotango não se relacionar com ninguém, ele vai ser "coletado". Ou não?

Sim.

Acho que o maior problema não é descobrir, mas dizer, eu ainda não consigo imaginar como é que a minha aplicação vai advinhar que o objeto pode ser passivado ou, pior ainda, ser "pego" denovo.

Se tá tudo solto na VM, eu tenho que usar uma estrutura pra reunir eles, será que essa estrutura (ou repositórios) como você já disse, já não são transparentes não? Existe algum outro meio de se reunir objetos que não sejam estruturas de dados?

Fritaaaaaaaaaaaaaaando

Ideia basica:

1 - A cada objeto criado, resitre ele numa estrutura qualquer
2 - Aplique um LRU e quando estiver sem memoria (um limite antes da memoria de verdade acabar, claro) passive os menos usados

Essa é a parte mais simples, que por si só já é complaxa.

Agora você vai ter que ter controle sobre todas as referências dos seus objetos, porque se alguem ficar segurando uma não adianta nada você passivar (o gc não chega nele). Vai ter que usar proxies no lugar dos objetos de verdade.

Bizarro

Acho que os Daos são beeeeeeeeeeeeem mais simples, não quero mais persistência transparente não

O rgande problema dos DAOs e da persistencia da maneira como eh feita hoje, para mim, e a pergutna:

Quando persistir algo?

Ao fim de um caso de uso? Ao fim de uma operaçao? Tpda vez que o estado for alterado? Quando? Quando? Quaaaaaaandooooooo?!?!

Se isso for 100% respondido numa aplicaçao, pode-se desenvolver mecanismos de persistencia bem razoaveis e translucidos

Notícias, artigos e o maior fórum brasileiro sobre Java