:x :x :x Putz, eu fico muito p da vida com isso, semrpe que mando um mail grande pra riojug, recebo a resposta antes do e-mail. Nem lembrava o que tinha nele! :x :x :x
Bom, vamos lá. A GoF define o Pattern Proxy [página 198 doi livro em português, para que como eu não tem cartão internacional e comprou na ciência moderna 
], que serve extamaente para esse uso. O exemplo [muito bom, aliás] dado na descrição é um editor gráfico que rpecisa trabalhar com uma figura muito pesada, que demora para carregar. em vez dele ficar esperando o troço ser finalmente carregado para deixar o usuário brincar com o programa, ele cria um objeto que possui a mesma interface que a figura teria [por exemplo: você pode mudar ele de lugar, apagar, etc.] enquanto a imagem carrega, incluindo todos os atributos do objeto que são “visíveis” [tipo altura e largura da imagem]. A gente vê muito isso [eu, pelo menos, já que tenho linha discada ] em browsers, quando carregam figuras. Creio que o Dynamic Proxy que o cv fala, da Reflection, tenha a ver com este padrão de projeto.
Supondo que com a reflection ou sei lá o que consigamos substituir o trecho em memória ocupado pelo objeto [considerando que seria muito mais simples fazer isso do que substituir todas a infinitas referências que um objeto pode ter] por um proxy muito mais magro, este proxy, quando ativado por alguém que mantinha referência ao objeto passivado, apenas chama o objeto real em disco, o coloca em seu próprio lugar e chama a mesma operação neste objeto, devolvendo a memória ao estando de antes da passivação. Pro cliente, seria transparente.
O problema é criar este proxy. Reflection, se funcionar mesmo [sei que prometi, mas ainda não li nada sobre o proxy :oops: ] poderia até ter uma lerdeza, mas a idéia aqui não é guardar objetos em disco a todo instante [como acho que alguns estão pensando, aqui e no JUG], mas sim utilizar em caso emergencial, para que sua aplicação não pare por falta de memória, então não sei se seria um problema tão grande, apesar da lerdeza reflection+serialization se bem considerável…
Não vejo muita fuga além de um agente do sistema de prevalência substituindo objetos ociosos por proxys quando o bicho pegar, mas…
Como vamos saber se um objeto é muito acessado, sem fazer ele implementar nem estender nada?
-
Utilizar DAO para ler a classe, assim saberíamos quando alguém requisitasse uma classe da persistência no primeiro acesso, ams quem garante que o cara não vai guardar uma referência para esta classe nele mesmo e mandar a gente se danar, nunca mais chamando o DAO rpa nada?
-
Agrupar os objetos persitidos em estruturas mínimas possíveis, contendo um grupo de objetos correlatos. Passivar toda a estrutura de uma vez, talvez utilizando a opção 1) para monitoria. Assim, teríamos os mesmos problemas, mas creio que a taxa de “passivação errada” seria menor, porque a tendência é que um objeto referenciado a outro seja chamado quando este for chamado, logo se mantivermos o grupo de “amiguinhos” do objeto X na memória, se rpecisarmos de algum deles quando chamarmos X , temos certeza que estarão lá. Uhm…isto está muito imaturo e confuso…
Bem, considerando o primeiro desfafio, de colocar um proxy substituindo o objeto original no endereço de memória deste, resolvido, como monitorar as consultas sem fazer com qeu o cliente tenha que se improtar se está utilizando o modelo de passivação do Space4J versão 2.5 ou o Prevayler 3.4 :?: :?: :?:
Ai meu são tanenbaum…
