| Autor |
Mensagem |
|
|
Só pra constar:
JMX - Managing J2EE with Java Management Extensions
Juha Lindfors, Marc Fleury - The JBoss Group
SAMS
ISBN 0-672-32288-9
Eu comprei há algum tempo na Tempo Real
http://www.temporeal.com.br/produtos.php?id=167562
[]s
|
 |
|
|
O livro de JMX do fleury é muito bom...eu até te daria o ISBN se não estivesse escuro no quarto agora, ou se pudesse acender a luz. A capa é azul...
|
|
|
|
Peraí... se toda alteração no objeto persitido deve ser feita pelos COmmands, e eu tenho uma referência à objA, ele só pode ser lido por mim, correto? Quando eu alterar, passo prum Command, este command vai implicitamente despassivar o treco e substituir pelo objeto que eu passei, podendo retornar esta nova referencia.
Tipo:
1)a -> objeto em lugar X
2)coloque o objeto no lugar X em disco
3)como o lugar X é apotnado por A, não é coletado
4)a lê x na boa
5)a modifica x e passa para um command de update
6)o command recebe o x, traz o passivado do disco, coloca num lugar y
7)comand faz as alterações em y, ele fica igual ao objeto em x
 command retorna y para o objeto a que o havia chamado [esse passo eu que inventei]
9)eventuais outros objetos que estivessem apontando para X se ferram com uma referência desatualizada
Falei alguma besteira grande ou foram só besteiras médias?
|
|
|
|
saoj wrote:
Por isso vou partir para a minha solução simplista que eu descrevi acima. Se conseguir alguma coisa descente eu aviso a voces.
Sérgio, eu posso estar doido, mas tenho quase certeza que o quê você está querendo fazer é um proxy, pelo menos o comprotamento é o mesmo.
Realmente, creio que só como um serviço, tipo o "console do administrador do sistema", o cara seleciona determinados objetos [imposto de renda de 1983?] e joga em hd. Eles estão lá, podem ser chamados em necessidade, como page faults em memória, mas enquanto não chega a hora...lazy...lazy zorra nenhuma, amanhã tem trabalho, fui!
[]s
|
|
|
|
cv wrote:
Nao eh possivel substituir nada na memoria. Quem gerencia isso eh a JVM, e a gente nao quer mexer nisso. Ou seja, todo o seu post foi pras cucuias - desculpe por trazer as más notícias 
Era o que eu temia, droga de graal do Proxy foi pro kct. Infelizmente, que vai jogar a toalha sou eu: se não tem como substituir um objeto por outro em memória de jeito nenhum, não dá pra substituir infinitas referências a um objeto [a droga da passagem por valores e não referência!], de que adianta eu criar um proxy no endereço 939393 se o objeto que instanciei a três dias vai procurar em 23323 ? Se não rola nenhuma plaquinha pra indicar "mudamos", já era.
Pelo visto, o jeito é a própria aplicação ter como selecionar um grupo de objetos e jogar eles na vala, ops, no disco. Legal, pena que isso quebra uma camada...uhm... alguém falou em BMP? damn
ai, ai, são knuth...
|
|
|
|
duardor wrote:
Na situacao hipotética (bem hipotética mesmo) que tenhamos MUITOOOSSS proxys de modo que apenas estes encham a memória, q poderemos fazer???
Proxys de proxys???
Um...de repente vc precisa tirar 1 ou dois dos hipotéticas, se estamos falando de servidores robustos [ou de efeito slashdot], não temos muito limites para esbarrar...
Bem, neste caso acho que realmente o negócio é jogar a toalha, rebootar o servidor e resgatar a última réplica enquanto manda o boy ir comprar mais memória! Acho que para chegar aqui, o problema tá na arquitetura de infra-estrutura, de repente o cara quis economizar e não uso um cluster, prevalência é lindiu, maraviliosiu, mas não é magikiu.
|
|
|
|
 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!
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  ] 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?
1) 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?
2) 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...
|
|
|
|
cv wrote:
Hmm... bateu uma duvida agora: como vc imagina ser notificado de que o sistema esta querendo acessar um objeto qualquer?
Este é o ponto. Não tem como, ao meu ver, sem substituir o conteúdo em memória por um proxy [falando, por enquanto do design pattern, não necessariamente de reflection] ou sacrificar a simplicidade obrigando que o objeto persistido implemente ou estenda algo 
|
|
|
|
Não poderíamos ignorar isso? Se eu dei um passivate num objeto e tem um cliente com referencia pra ele, azar. O passivate não vai liberar nenhuma memória, e o cliente pode continuar usando o objeto normalmente. As chances disso acontecer seriam baixas, pois se há clientes com referencia para o objeto, isso significa que ele foi acessado recentemente e provavelmente não estará elegível a passivação.
E como eu saberia que a classe foi acessada? E a liberdade do OO? [mais sobre isso abaixo]
Minha idéia não é colocar um proxy, mas uma versão passivated do objeto que vai possuir apenas a chave primária e mais nenhum campo.
Bom, o cv falou sobre isso, então vou me ater a dizer que isto me lembra este post aqui: http://www.jroller.com/comments/pcalcado/Weblog/can_prevalence_resist_bad_design
Não escreva nenhum objeto final, do mesmo jeito que vc não pode escrever nenhum objeto não serialized.
Uma vez eu li em algum lugar que utilizar qualquer coisa final era ruim. eu concordei e me perguntei porque raios existe a droga do final, se é só rpa constantes, sei lá. Aí eu li o Effective Java e percebi que realmente tudo tem seu lugar. Não vou comentar o livro aqui, a Bani tem um ótimo resuminho no blog dela, ams recomendo que realmente leiam, muito bom, mesmo. O que importa é que: sim, existem necessidades de se implemetar algo final, principalmente num projeto bem feito. Talvez objetos final possam ter que ser serializados "na mão", mas algum jeito tem que ter!
Teríamos que ter um timestamp lastAccessTime
I see dead POJOs.
Essa situação é muito interessante !!! E acho que a única solução é:
Para coisas que crescem indefinidamente, como um log de acesso, vc precisa rotacionar a coisa. Não tem jeito !!! Esse log precisa ter um tamanho máximo !!! Esse problema tb acontece com um banco de dados relacional e com o log do Apache.
Eu pensei neste exemplo a primeira vez há algum tempo, quando o wiki do Prevayler caiu. É só um exemplo, mas pense: você tem um site com mil acessos dia, você limpa sua "base de dados" de acessos todos os dias [tipo os referres do JRoller], aidna que a taxa de acessos triplique, seus vários GB de memória iriam aguantera fácil...só que você não pdoe prever a demanda de um dia assim. Ok, pdoe não acontecer nunca, mas se estamsof alando de alta disponibildiade e missão crítica, temos que pensar neste tipo de tragédia.
cv, vou dar uma olhada na Proxy, depois comento teu post.
E agora, com licença que minha linha é discada [não riam muito alto, por favor!] se tiver alguém acordado para comentar isso, talvez eu ainda leia.
[]s, galera
|
|
|
|
Kct, eu postei uma resposta na riojug de manhã e ainda não chegou
Vamos ver se consigo lembrar o que estava escrito...
Meu ponto de vista é o seguinte:
1) é necessário
2) é complexo pra kct, até alguém colocar um ovo em pé  e deixar a gente com cara de babaca 
3) A performance [falando especificamente da mensagem do Elizário, an RioJug] não iria cair se só fosse utilizado quando houvesse risco de estouro de memória
---
Considerando que precisamos manter a estrutura de POJOs:
1) como colocar um objeto em memória auxiliar sem saber quanta gente está "apontando" para ele?
2) Ainda que saibamos, como colocar um proxy no local, falando especificamente em gerência de memória, ou como substituir todas as referências, que podem ser privadas?
3) Ainda que consigamos colocar um proxy, este proxy estende o objeto serializado [afinal, deveria prover uma interface igual aos clientes do serializado], se sim, e se tivermos uma classe final?
4) como saber se um objeto foi lido recentemente ou não? Poderíamos ter um objeto quase imutável, talvez que forneça uns parâmetros tipo "índice da taxa de juros COPOM", que são modificados uma vez a cada mês/ano/década/nunca, mas que são cosntantemente acessados e precisam estar disponíveis. Limitar o acesso via algum wrapper ou através de DAOs, Commands, transactions, whatever iria limitar e muito nossas possibildiade sno uso de Prevalência
---
Situação em que seria necessário um passivate, siga os passos:
1) Você tem um site.
2) Este site registra um pequeno objeto com o IP e hora de cada visita.
3) Você usa prevalência.
4) Seu site é bom rpa cacete e aparece no slashdot.
5) Sua JVM morre
Se a droga do mail chegar eu colo aqui, mas creio que era basicamente isso...
|
|
|
|
Resposta semelhante...intrigante.. quem será que mandou?
[]s
Re: [java-br] Web Services
De:
Phillip Calçado <phillip_listas@yahoo.com.br>
Para:
java-br@yahoogrupos.com.br
Data:
Hoje 16:03:26
Oi,
O grande problema com webServices é que a maturidade da tecnologia não é nem
a metado do hype que é feito em torno dela.
Seu exemplo seria perfeitamente viável com RMI-IIOP ou se você serializar os
objetos e enviar por sockets. utilizar WebServices implica colocar um
protocolo a mais em cima da pilha de protocolos que já são utilizados,
WebServices em SOAP são baseados em arquivos de texto e XML, excelentes para
integrar aplicações em tecnologias diferentes [Java x Delphi, Java x doNOT,
etc.] mas se a comunicação é e vai continuar sendo Java x Java, utilize os
recursos que a linguagem oferece. Utilizando WS você só vai perder
perfomance, se a aplciação requisitar segurança alta, então, putz... carroça!
Se for trabalhar numa base web, ainda assim esqueça WebServices por enquanto
e procure uma alternativa com um Servlet passando objetos serializados por
HTTP (como se fosse um download/upload) diretamente para seus clientes Swing.
Já vi cases assim, funciona bem.
Pode parecer que é mais fácil ter um grande overhead e utilizar WebServices,
que são até bem simples de serem feitos, mas você vai perder performance sem
ganhar nada em troca.
[]s
|
|
|
|
Oi,
usa um listener na sua sessão 
http://edocs.bea.com/wls/docs81/webapp/app_events.html
http://www.onjava.com/pub/a/onjava/2001/04/12/listeners.html?page=1
[]s
|
|
|
|
Oi,
Crie um classe utilitária com métodos para fazer login e logut. Quando fizer login, além de armazenar um referência no atributo da sessão para o tal objeto que identifica o usuário, coloque numa Collection em escopo de aplicação [disponível a todas as sessões] uma referência à este objeto identificador.
Só não se esqueça de utilizar um método na classe utilitária para fazer logoff que não só remova o atributo da sessão bem como da Collection que está guardade em escopo de alicação, se não você vai ter lixo em memória.
Na hora de lsitar os usuários, pegue o Collection em escopo de aplicação e msotre seu conteúdo.
Uhm...acho que ficou confuso, mas é isso aí!
|
|
|
|
Bom, trabalhando com uma equipe de 7 designer [é, sete, tirem os queixos do chão  ] eu aprendi alguma coisa.
1) Se o webdesigner for artista apenas, arrume outro pra fazer XHTML e deixe o rpimeiro no Photoshop
2) Se precisar fazer uma alteração boba, faça na mão, a menos que queira que demore uns dias pra ter a droga do HTML
3) Faça tudo em um HTML tosco em paralelo, quando chegar a hora, dê ao estagiário para integrar com o HTML bonitinho e verifique depois
4) Sempre que pedir algo, especifique nos mínimos detalhes o que for importante, alguns rpeferem fazer uma figura e passar [tipo Paper Prototyping], eu prefiro abrir o BlueFish ou NVU [ http://www.nvu.com ]com a idéia
5) Ensinem os designers a usar CVS ou outro treco de versões., ou pelo menos a organizar a bagunça que eles chamam de diretório
6) Designers NÃO sabem planejar e NÃO sabem organizar. Eles precisam de um briefing por semana e 1 hora para fumar por dia.
7) Quando ele colocar sua linda tabela dinâmica em um Flash, bata a cabeça na parede não mais que três vezes. Ok, se o cliente viu a tabela em Flash e aprovou deste jeito antes de você ver, pode bater mais...unm... cinco vezes.
|
|
|
|
|
Que nada, rapaz, vcs são preconceituosos. Eu já recebi curriculum de gente com 20 anos de experiência em Linux, pô!
|
|
|
|
|
|