Eu acho a idéia de prevalência muito interessante e o Klaus merece os méritos por ter reunido essas idéias no Prevayler.
Mas parece que a filosofia de jogar o banco de dados no lixo e o marketing agressivo do Klaus está incomodando algumas pessoas.
Vejam isso aí embaixo: :shock:
http://jroller.com/page/fate/20041230#the_real_interview_with_klaus
Ah, o Hani faz isso com todo mundo.
Rafael
Mas a maneira que o KLAUS faz propaganda do prevayler deixa qualquer um … OLHA A PERGUNTA “VOCÊ AINDA USA BANCO DE DADOS ?”
“Tome a pilula vermelha e seja liberto”, “Quem usa banco de dados está Ultrapassado”…," banco de dados é um Câncer"…
Por Favor dá licensa meu, só pelos motivos dessas frases nem mesmo cheguei a testar o produto. todos nós sabemos ninguém é bobo, os Bancos de dados “ainda” são um meio maduro e seguro de guardar dados . prefiro db4objects ou então Space4J que eu acho que é um projeto Brasileiro também(Ainda vou dar uma olhada em Space4J).
A ARROGANCIA É O PRIMEIRO E UNICO PASSO PARA A DERROTA.
100% PostgreSQL - License BSD AHAUHAUHAUHAUHAUHAUHUAHAUUAHUHAUHAUHAHAUHUAHAU
+Hibernate ou Ibatis AHAUHAHAUHUAHAUHAUH
Marketing maduro e Humilde tem bastante chanses de ser bem sucedido.
essa cara aí é bem sensacionalista…
o sistema do prevayler é bom, mas se o cara não manerar, o pessoal vai pegar raiva dele e não vai usar por causa dos exageiros que ele fala
HUAHAHUAHUHUAHAUHUAHUAHUAAHU!! :lol:
Quando eu crescer quero ser igual ao Hani 
ficou menos comica que a original.
Tambem achei, mas po, imagino que seja MUITO dificil superar a entrevista original nesse quesito, louds…
(Alias, pra quem nao sabe, sim, eu dei uma mao no Prevayler. Sim, eu acho e sempre achei o marketing do Prevayler meio palhacada.)
Eu ainda acredito em prevalência, desde que o framework tenha:
:arrow: Cluster
:arrow: Indexação
:arrow: Passivação
:arrow: API o mais simples possível
:arrow: Um monte de comandos CRUD pré-prontos
:arrow: Um mecanismos de replicação assíncrona (de madrugada) dos comandos para um banco de dados, o tal do executeSQL, porque viver sem banco-de-dados ainda não é possível.
:arrow: Talvez uma linguagem tipo SQL para fazer writes sem ter que ficar codificando comandos sempre. (Não sei se isso é bom, nem se é possível)
Também ainda não sei como se previnir de um comando muito demorado que coloque o sistema todo num hault, já que por definição todos os writes são em série, e não em paralelo. Fazer lazy-evaluation de um comando é extramamente complicado e inviabiliza a replicação (cluster) e a premissa de um commit, eu acho… 8)
Huhahaa…a original é a mais cômica!
É verdade… eu acho q a ausência de replicação automática(instant on),com um slave virando master na queda deste, o que falta de principal no Prevayler…(todo mundo de bd pega no meu pé com isso…)
Sérgio,ainda não usei o Space4J, mas estou animado em testar!
Vou dar uma passada e baixá-lo…
Acho q o excessivo “Hype” do Klauss vai fazer os desenvolvedores migrarem para outras soluções prevalentes logo,logo…
Vejamos,
Clustering na forma como existe no prevayler/space4j não é clustering mas sim replicação master/slave que a única utilidade que conseguiram encontrar é para aliviar o problema do snapshot.
Indexação em um sistema ‘prevalente’ para mim é um java.util.Map, ou tem algo mais que tou perdendo?
Passivação, tirando que fazer isso sem usar uma JVM modificada é proibitivamente caro, vai meio de encontro com o lema da prevalência, que é “sempre e tudo na memoria”, não?
API simples? Ate ai as APIs já são simples, ou melhor, são simplorias.
Quando a uma linguagem de consulta e alteração mais simples e prática. Poderia se usar OGNL, por exemplo, ou XPATH/XQUERY/XUPDATE/XPQP. Já quebra um super galho.
Pessoalmente, eu sou muito mais usar http://research.sun.com/forest/opj.main.html que Prevayler.
[quote=louds]Vejamos,
Clustering na forma como existe no prevayler/space4j não é clustering mas sim replicação master/slave que a única utilidade que conseguiram encontrar é para aliviar o problema do snapshot.
[/quote]
Verdade! Mas a idéia também do cluster seria para rodar o Prevayler/Space4j em ambientes distribuídos, como um site com várias máquinas web em load balance. O cluster do Space4J está bonitinho, só falta fazer um stress teste para validá-lo. Falta tb tratar o caso de quando o master cair, para algum slave assumir. Não tenho idéia de como fazer isso…
Na maioria dos casos vai ser isso mesmo, mas seria legal um framework para organizar isso, principalmente para oferecer reindexação automática de objetos mutáveis. Também tem o lance das chaves compostas. O Space4J tem um framework de indexaçáo com Observer/Observable para fazer a reindexação automática. Dessa maneira, o cara cria um índice e ignora que ele existe. Pode adicionar, remover, alterar os seus objetos numa lista comum e ignorar a indexação. Como nos bancos de dados…
Verdade, mas acaba sendo a única saída (eu acho) para os casos que não há memória suficiente. Por exemplo, se botássemos esse fórum todo aqui em memória, imagina quantos objetos inúteis ficariam em memória. Posts antigos que ninguém mais vê. E num site com um milhão de cadastros que só 10 mil aparecem para se logar por dia? Deixar essa galera toda na memória é desnecessário. Agora se o cara arranjou uma máquina com 40 Gb de RAM, beleza, esquece a passivação!
[quote=saoj]
Verdade! Mas a idéia também do cluster seria para rodar o Prevayler/Space4j em ambientes distribuídos, como um site com várias máquinas web em load balance. O cluster do Space4J está bonitinho, só falta fazer um stress teste para validá-lo. Falta tb tratar o caso de quando o master cair, para algum slave assumir. Não tenho idéia de como fazer isso…[/quote]
Para isso ou vc precisaria expor a interface de execução de comandos para as demais máquinas executarem remotamente os comandos no master e introduzir um spof ou então suportar replicação multi-master, que é seria mais dificil.
Quanto a passivação, da forma como você descreveu parece mais 1 OODBMS meia boca que um sistema ‘prevalente’.
Mas Sergio,
me diz uma coisa, o db4o me parece, eh muito bom pra armazenar objetos em disco. E se fosse feita uma cama “intermediária” que tivesse a responsabilidade de descidir c o objeto vai pra RAM ou pro HD e que ainda ficasse vasculhando a RAM e “baixando” os objetos que estão sem uso, seria viável, ou não?
Alias, como posso ajudar no desenvolvimento do Space4J?
VELO
Nao eh viavel saber quais objetos devem ir pro disco sem uma boa dose de conhecimento sobre o grafo de objetos em questao, coisa que nao da pra ser implementada de forma generica tao facilmente. Nao que seja impossivel, mas eh um trabalho bem consideravel, e a performance no fim das contas ia ser um tanto quanto, uhm, como colocar isso de forma positiva? - ridicula. 
Já viu alguma implementação disso cv?
Onde?
Real, mesmo nenhuma, mas o unico jeito de fazer isso sem partir pra ignorancia (por exemplo, usando AOP) que eu vejo eh embolhando todos os objetos persistentes em um dynamic proxy hiper-mega-inteligente, que tem algum algoritmo pra determinar o que vai pro disco e o que fica, e recuperar os objetos do disco quando algum acesso eh tentado. Falando, ate parece facil, mas interceptar absolutamente todos os acessos a todas as instancias do seu grafo sem deixar vazar nada, e sem estragar a brincadeira (ou seja, ter que mexer no grafo pra adaptar ele pra esse modelo), eh muuuuuuuito punk. Factivel, assim como construir uma bomba nuclear caseira tambem eh, mas se alguma coisa der errado, voce vai passar um longo tempo juntando os cacos :mrgreen:
Eu tava pensando numa ideia diferente…
Colocar uma camada intermediaria responsável por colocar no db4o ou no space4j(ou prevayler), ou seja, a cama intermediaria escolhe entre o HD e a RAM. Na hora que for solicitado esse objeto à camada intermediária, ela vai realizar o GET no dois sistemas (HD e RAM), e vai retornar o que ele axar. Quando o objeto estiver na ram, maravilha, vai ser instantaneo, no HD vai demorar, mas se tah no HD algum motivo tem (eh velho, naum eh importante, sei lah). Essa camada intermediaria seria responsável por vasculhar a RAM e ir guardando as coisas “velhas” no HD. Objetos q são acessados no HD pode ser promovidos pra RAM. Eu toh brincando num negocio assim.
O unico problema é que o start do db4o é muito, mas muito mais simples que dos sistemas de persistencia em memoria. Com 3 linhas de codigo gravo um objeto. Nas persistencias toh tendo que fazer 3, 4 classes ou metodos, e ainda com um agravante, naum consigo gravar um objeto Object (pode ser cagada minha, mas prevayler eu comecei a mecher ontem).
Com relação a definir c vai pra ram ou pro HD, pode-se obrigar a implementação de interface que tenha um boolean e um Date. O boolean quando false é default no HD, não sobre pra RAM. E se o objeto tiver mais q X dias(date), vai pro HD. Mecheu nele, atualiza o Date e sobe pra RAM.
Sei lah, possivel é. Que nem diz uma cara q eu conheço, na informática tudo é possivel. Se alguem diz q não dá, ou é muito caro, ou o cara não qr fazer. A 2 anos atrás, o que vocês falariam do looking glass?
VELO
E se eu tivesse um “dynamic proxy hiper-mega-inteligente” que primeiramente procurasse meu querido objeto em um uma pilha atualizada de tempos em tempos com objetos randomicamente selecionados?
Qual a probabilidade de ele achar o objeto que ele quer lah?
Será que isso não seria mais eficiente que definir regras genéricas considerando outros fatores não?
Meio bobosort isso, não?!
[quote=Diogenes]E se eu tivesse um “dynamic proxy hiper-mega-inteligente” que primeiramente procurasse meu querido objeto em um uma pilha atualizada de tempos em tempos com objetos randomicamente selecionados?
[/quote]
Randomico?.. isso não inclui colocar objetos em desuso e memoria e acabar arquivos itens q são frequentemente usado?
Tem algum jeito de eu iniciar o prevayler ou o SPace4J simples assim?
public void inserir(Object o){
ObjectContainer db = Db4o.openFile("src/bancoObjetos/db4o/te.yap");
db.set(o);
db.close();}
Eu não consigo iniciar ele simples assim, sou taum burro assim?
tipo um cache?