Pegaram pesado!

Assuntos Gerais
#41

Jah vi, mas se viu o tamanho?!

Tah, não é enorme, mas nem se compara, 3 linhas pra adicionar algo no db4o, no Space4J eh mais complexo, no prevayler, nossa, nem se compara.

o meu galho tá aqui:

[code] public void addNumber(String user, String number) throws CommandException,
LoggerException {

    space4j.executeCommand(new MapPutCmd("phonenumbers", user, number));
}[/code]

Eu queria fazer ± isso:

space4j.add(Object object);

Enfim, facilitar ao maximo o ADD…

Toh tentando fazer isso (ontem eu tava hoje naum fiz), mas soh consegui exceptions…

VELO[/quote]

Fala Velo !!! Me explica o que vc quer fazer e porque vc não achou a API do space4j simples. Talvez vc tenha razão e haja jeitos de melhorá-la.

Quando a linha space4j.add(Object obj) não funciona pois a premissa é vc fazer as alterações através de comandos, para que esses fiquem logados em disco.

Mas coloque aqui suas críticas ao space4j que com certeza deve haver coisas para melhorar. O que vc não entendeu ???

Tem como simplificar ainda mais a API do Space4J ??? Se tiver me fala que a gente faz na hora… :slight_smile:

#42

Toda vez que eu converso com o Klaus ele me convence que Passivation é desnecessária, e que se o Prevayler/Space4J forem por esse caminho eles vão acabar virando um OODB.

Mas depois de um tempo, quando eu começo a ver que apesar de poucos, haverá casos em que vai faltar memória, eu começo a pensar na viabilidade da porcaria da passivação.

[quote=cv]Como voces vao saber quais objetos estao sendo usados e quais devem ser passivados?
[/quote]

Todo o objeto passível de passivação é acessado via proxy e dentro desse proxy tem um lastAccessTime. De vez em quando um monitor corre o passivation map e passiva todos os objetos que estão sem acessos a X minutos.

Complicado isso realmente pois fazer um full sem índices percorrendo a lista inteira de objetos vai acabar trazendo todos os seus objetos de novo para a memória, a não ser que vc use úm índice, e índices nunca são passivados. Então em teoria as queries seriam feitas nos índices em memória e não no objeto que foi para o disco passivado.

Uma merda isso mesmo! Solução para evitar dores de cabeça: Cada máquina cuida da sua própria passivação isto é, um objeto passivado numa máquina pode não estar passivado em outra máquina, pois os acessos são diferentes, isto é, numa máquina ele pode ter sido acessado muitas vezes e em outra não.

E quando restartar o sistema, o que vale são os objetos passivados no MASTER, ou seja, a passivação dos slaves são ignoradas e vale a do master.

Não me lembro disso direito (faz quase um ano que eu não mexo no space4j) mas acho que o ato da passivação é uma alteração no space e fica logada no LOG. Isso é fundamental para garantir a consistência, ou seja, a passivação é um commando (writer) como qualquer outro, que remove um objeto do Space e mete ele no HD, deixando no lugar dele um proxy malandro.

Isso tudo aí em cima é bonito de se falar, mas quando vc vai implementar, dá um trabalho do cão e faz uma sujeira danada. Espero que um dia esse esforço se pague ou esse framework ficará perdido como um ELEFANTE no meio da simplicadide do Space4J.

Além disso, se vc não tomar cuidado, todos os seus objetos vãi ser passivados e vc vai acabar com um banco de dados de objetos serializados em disco. Nada performático como o CV falou!

#43

Isso me parece mais uma receita de memory leak do que qualquer outra coisa. Como voce garante que todas as referencias ao objeto foram substituidas pelo “proxy malandro”?

#44

O maior problema de usar proxies é resolver o seguinte caso de uso:


class TodoProxyMeOdeia implements ModificationListener {
  public void fazX(IResource resource) {
     resource.truncate();
     resource.addContentModificationListener(this); // <-- KABOOM!!
  }
}
#45

Não axo a api do space4j complicada, em absoluto, achei muito mais facil de entender/usar do que o prevayler :stuck_out_tongue:

Mas eu axo que falta um caminho + simples.

As vezes o fulano só quer adicionar na memoria e pegar deSpois. Faltou uma maneira direta, digados, de adição.

Um codigo fala mais que mil palavras…

public void inserir(Object o){ ObjectContainer db = Db4o.openFile("src/bancoObjetos/db4o/te.yap"); db.set(o); db.close();}

Com o db4o dá pra fazer esse esquema, claro, não vou ficar abrindo e fechando o banco toda vez, mas é possivel adicionar qualquer coisa em 3 linhas, pra recuperar a info tbm precisa de poucas linhas.

Uma coisa, não é mais facil fazer a busca em arquivos XML?

[quote]<dados>
<nome>USERNAME=marvin</nome>
<data>2005-01-21 08:18:57.428 AM</data>
</dados>[/quote]

Alias, o prevayler usa dados serializados, o Space4J faz como, se não me engano ele não me obriga a serializar… E porque não pode ser usado um XStream da vida, não fica mais facil de fazer query?

VELO

#46

Talvez vc tenha razão e valha a pena colocar alguns métodos no space4j para encapsular comands CRUD (Create, Update, Delete). Vou pensar nisso…

Todos os objetos tem que ser serializados, se não não dá para tirar o snapshot. Da mesma maneira são todos os atributos de um comando, que vai ser serializado no log. (Não entendi a sua dúvida!)

#47

Isso pode ser um problema mesmo, mas citando o Klaus:

Eu diria que programar com prevalência é como programar com threads. Se vc não prestar atenção no que está fazendo, vai acabar fazendo caca, independente das suas habilidades como programador.

Então para resolver esse problema, vc tem que lançar alguns postulados:

:arrow: Se vc for usar passiavation, vc vai colocar os seus objetos passíveis de passivação dentro do PassivationMap, e quando vc for pegar o seu objeto de dentro do PassivationMap, vc vai receber um PROXY e não o objeto em si, que pode estar dentro do proxy ou no disco.

:arrow: O seu programa só pode guardar referências ao Proxy e não referencias diretas ao objeto. Ele pode acessar o objeto que está dentro do proxy a qualquer momento, mas não pode criar uma hard reference para esse objeto, caso contrário a passivação não vai servir pra nada, pois o objeto não será coletado e continuará na memória, e pior ainda, ficará na memória e no disco criando uma inconsistência.

Prevalência tem um monte de outros postulados, e se o cara não conhecê-los, e caca na certa. Outro postulado importante:

:arrow: Vc não poderá, sob pena de morte, fazer alterações em seus objetos sem ser através de um Command.

Infelizmente nada impede um programador destraído ou maluco de sair alterando os objetos por fora de um comando.

Outro:

:arrow: Se vai fazer iteração numa lista, vc precisa de um safe iterator (Space4J) ou precisa enviar uma query (Prevayler) para não correr um risco de receber um ConcurrentModificationException.

Mas nada impede o cara de pegar uma lista e sair itinerando. :frowning:

Logo a conclusão é: Se for brincar com prevalência, conheça muito bem e aplique a toda hora os postulado, da mesma maneira que se vc for trabalhar com relatividade saiba que a velocidade da Luz terá que ser sempre constante no vácuo, independente da velocidade do observador. Se não é caca !!!

#48

Eca. E esse monte de complicacao e regrinha decoreba era pra se livrar da dificuldade de mexer com bancos de dados? Hmm. Ah, tah, so pra saber.

#49

É, prefiro continuar com banco de dados, muuuuito mais simples… :mrgreen:

#50

Isso, certa vez eu perguntei como fazer pra usar os mesmo objetos utilizados com o prevayler com outras linguagens.

Ai comecaram a me responder: "Tu cria uma camada e acessa com socket… "
sai antes de terminarem de responder.

#51

[quote=marcelomartins]Isso, certa vez eu perguntei como fazer pra usar os mesmo objetos utilizados com o prevayler com outras linguagens.
[/quote]

Não entendi o que vc queria fazer. Pode explicar melhor?

Eu não sou o Klaus, e não quero ser louco de defender com unhas e dentes a utilidade/viabilidade/performance/poder etc e tal do Prevayer/Space4J.

Eu apenas acho que prevalência é uma mudança de paradigma muito interessante, que te faz pensar nas coisas de maneira inversa ou louca. E isso sempre é bom para experiëncia/amadurecimento e outras coisas mais…

Isso é chato mesmo, principalmente para o cara que nunca viu prevalëncia e vai fazer o seu primeiro programa. Mas como fugir disso? Parece que o Hibernate foi o projeto mas bem sucedido nesse sentido, pois para fazer um bean do hibernate vc precisa fazer NADA.

Tá bom, vc precisa ter um construtor sem parametros, precisa preencher um arquivo XML (odeio preencher arquivo xml :cry: ), configurar o seu banco de dados, e colocar tudo pra rodar, mas pelo menos o código do seu bean fica praticamente virgem.

#52

[quote=marcelomartins]
Isso, certa vez eu perguntei como fazer pra usar os mesmo objetos utilizados com o prevayler com outras linguagens.

Ai comecaram a me responder: "Tu cria uma camada e acessa com socket… "
sai antes de terminarem de responder.[/quote]

Mas eu tava querendo bem isso :smiley:

Pq um oracle o q eh, eh um socket q fika esperando SQL, fale o q falar, acaba sendo isso.

VELO

#53

Me diz uma coisa, objetos serializados com XML não são + faceis de fazer query e/ou montar visualizadores?

VELO

#54

[quote=velo]Mas eu tava querendo bem isso :smiley:

Pq um oracle o q eh, eh um socket q fika esperando SQL, fale o q falar, acaba sendo isso.[/quote]
Sim, a diferença é que no Oracle ou outros servidores de banco de dados é que já ta pronto, eu só preciso conectar e isso não vai influenciar no desenvolvimento do meu sistema. Vou me preocupar somente em resolver o meu problema.

Agora, se eu tiver que fazer isso então vou ter a impressão de estar voltando uns 30 anos (ou mais) no tempo.

Imagina uma empresa normal. Essa empresa tem sistemas em Java, VB, Foxpro e ZIM.

Como vou fazer os sistemas em VB, Foxpro e ZIM acessarem os dados que estão prevalecidos no Java?

Ou será que eu vou ter que ter minha base de clientes repetida nos varios sistemas? Ou será que eu vou ter que passar 6 meses criando um sistema pra integrar as linguagens? Será? Será? :lol:

Poiseh!

#55

[quote=marcelomartins]
Imagina uma empresa normal. Essa empresa tem sistemas em Java, VB, Foxpro e ZIM.

Como vou fazer os sistemas em VB, Foxpro e ZIM acessarem os dados que estão prevalecidos no Java?

Ou será que eu vou ter que ter minha base de clientes repetida nos varios sistemas? Ou será que eu vou ter que passar 6 meses criando um sistema pra integrar as linguagens? Será? Será? :lol:

Poiseh![/quote]

Uhm…problemas. O Prevayler/Space4J não vai deixat você fazer isso, simplesmente porque não deveria.

Usar SGBD como middleware entre sistemas é uma péssima prática, que acaba em muitos problemas. Ok, isso é o que mais tem por ai, mas o que mais tem por ai eh programa em VB e nem por isso essa porcaria é boa :wink:

Seu sistema X não deveria consultar a tabela de clientes de um SGBD, alterá-la e coisarada, ele devia era consultar o subsistema/sistema de gerenciamento de clientes.

Um sistema prevalente ou com outro tipo de persistência pode muito bem transformar seus objetos em coisas flat como tabelas para passar numa consulta, a pergunta é: ele deveria fazer isso?

Resumo da ópera: [color=red][size=24]não[/size][/color] use SGBD como middleware. Vamos fazer mais uma campanha, desta vez com leões-marinhos…

[]s

#56

Integracao atraves do banco de dados eh soh um dos jeitos de fazer duas aplicacoes conversarem. O ponto do shoes aqui eh que esse tem muitos contras, mas tambem alguns pros interessantes, que se forem realmente necessarios, devem ser aproveitados.

(licao de casa por hoje: http://www.eaipatterns.com :D)

#57

Hehe :smiley:

Shoes, concordo contigo 114%, mas tem uns detalhes.

Eu acho interessante levar nossa discução para o mundo real a nossa volta, e não ficar apenas imaginando o mundo perfeito. Ter um subsistema/sistema de gerenciamento de clientes é perfeito, mas eu particularmente nunca vi isso em lugar nenhum.

Agora pensando, em todas as empresas que conheci (de multinacional até o mercadinho), todas elas tinham vários sistemas e em todas elas em algum ponto o SGDB fazia o meio de campo (sem opção de mudar tudo). E é desse ponto e dessa minha experiência que eu coloco minha opinião.

E partindo desse principio que eu digo que na minha opinião, o conceito de prevalencia é muito restrito. Para mim serviria para o meu sistema de indexação de mp3, que é uma ilha e não esta inserido em um contexto maior.

Acho que enquanto as coisas forem assim, o não existe muito lugar pra prevalencia em grandes empresas, o Klaus querendo ou não. Essa é minha opinião.

PS.: Phoda é a galera postando num domingo com 35 graus la fora. O vicio :stuck_out_tongue:

#58

Pois é, Marcelo, mas é como falei no post anterior. Você quer manter as cosias como estão ou buscar melhorar? Se for para ficar mais coerente com 99% dos lugares por aí, vamos falar de aplicativos em Delphi acessando Stored Procedures para sempre, ninguém evolui sem abandonar velhas práticas :wink:

Nem estou falando em prevalência exatamente, estou falando em usar um SGBD para a finaldiade do SGBD. Se você começar a colocar tabelas sendo acessadas por todo mundo, vai ter que garantir a integridade (uhm… stored procedures, triggers…essa bagaça toda) e vai elvar sua aplicação para dentro do SGBD, e isso é tema de vários outros tópicos.

[]s

#59

[quote]
Pois é, Marcelo, mas é como falei no post anterior. Você quer manter as cosias como estão ou buscar melhorar? Se for para ficar mais coerente com 99% dos lugares por aí, vamos falar de aplicativos em Delphi acessando Stored Procedures para sempre, ninguém evolui sem abandonar velhas práticas[/quote]

Radical!!! :twisted:

“Todo poder aos bolcheviques. Morte a bastilha. Liberdade (ainda que tarde)”.

Camaradas. O momento da luta não pode mais esperar. Vamos, companheiros!!! Peguemos nossas armas e lutemos contra os opressores tecnológicos, velhos gagas, matadores de foquinhas e violadores da justiça…

Mmmm … Tem alguma outra solução um pouco menos radical ? :wink:

#60

:oops: Mas, também estaria sendo radical se eu não contextualizar…

Acho que o negócio destas camadas de persistência é ter uma forma suave para fazer a transição dos SGBD atuais.

Por exemplo… “os bancos faziam o meio de campo…” Bom, então que objetos (gradualmente) façam o meio de campo. Já vi mais de um projeto cujo um dos princípios era tirar de foco o banco de dados como o grande centralizador dos sistemas. Começando ali uma historinha de objetos distribuidos e webservices… Este pessoal da OMG e da W3C, tem cada idéia né !? :roll: Onde já se viu criar um padrão para comunicação entre objetos distribuídos? Quem vai usar isto?

Enfim, pouco a pouco, tomando uma atitude simples, um novo paradigma é edificado.

ps: morte as foquinhas !!! :twisted: