Bom dia!
Estou com a edição número 1 da Mundo Java e, para quem não comprou, ela contém uma matéria extensa comparando tecnologias de acesso a dados em java.
Após lê-las (!) todas, eu pergunto para vocês que já tem mais experiência do que eu: [b]por que não usar prevayler?
Bom, alguns motivos pelos quais nao eh uma boa pedida usar o Prevayler:
:arrow: Voce tem um volume de dados maior que a RAM, ou esta planejando um crescimento no volume de dados maior do que a sua capacidade de adicionar RAM a maquina
:arrow: Voce tem que fazer integracao com outras aplicacoes atraves de um banco de dados - esse eh, talvez, o caso mais tipico, e mais sacal de todos…
:arrow: Voce tem um modelo de dados que nao “encaixa” bem em objetos (alguns calculos matematicos, por exemplo), e uma base de dados especializada encaixaria melhor
:arrow: Voce tem um volume de gravacoes muito maior do que o de leituras - nesses casos, a performance do Prevayler acaba ficando parecida com a de um RDBMS, ja que ele tem que sincronizar cada adicao ao log (claro, vc pode desligar o sync(), mas perde bastante da seguranca de que os dados vao ser mesmo gravados em disco por completo)
Bom, acho que eh soh… se alguem lembrar de mais algum, dah um toque 
Opa cv, boa tarde.
Tenho algumas dúvidas:
A proporção quantidade de dados X ram se dá como?
Por que, como no seu exemplo, cálculos matemáticos não se dão bem com objetos?
1 - Para cada Megabyte utilizado pelos seus objetos voce desconta 1 megabyte da sua ram.
2-Isso depende do modelo e estrutura de dados que você ta usando, mas no geral isso não influencia muito o uso do prevayler.
Existem pelo menos 2 outras sistuações onde o prevayler não é indicado:
-Transações longas, uma de suas transações precisa ficar parada esperando dados externos.
-Transações que não são determinísticas, com a mesma entrada diferentes resultados são possíveis e válidos.
aproveitando que vocês tocaram no assunto de transações, eu li na documentação do prevayler que ele não utiliza rollback, para tal você apenas tem que determinar que a transação é inconsistente antes de começar a aplicá-la. (e lançar as exceções necessárias), tudo bem que você pode checar tudo que vai dar errado porque todos os dados estão disponíveis e todas validações são executadas antes que qualquer coisa seja mudada de fato como o cv diz em seu artigo “An introduction to object prevalence”(me corrija se eu estiver errado), mas se eu lanço uma exceção para uma transação, eu continuo garantindo a atomicidade desta transação?
Somente se essa exceção for lançada antes de qualquer alteração.
O ponto que eu queria ilustrar mesmo é que vc não precisa de rollbacks se vc conseguir checar se vc pode fazer tudo que precisa fazer sem erros.
Até hoje ninguem deu um exemplo de onde isso seja impossivel ou impraticavel, mas de qualquer forma a gente implementou rollbacks no Prevayler 2 - tem pouca documentacao, mas da uma olhada nos sources
Isso me lembrou a muvuca sobre mecanismos de persistência do Abaporu. 
[]'s
Podemos concluir entao que qualquer sistema comercial e profissional, de qualquer porte, não deve ser implementado usando o Prevayler…
Todo os sistemas que conheco, principalmente internet, usam muito os recursos transacionais de banco de dados (INSERT, UPDATE e DELETE), e sempre teem uma quantidade de dados muitas vezes maior que o montante de memoria dos servidores…
Acho o Prevayler interessante, mas aplicavel somente em pouquissimos casos…
[quote=“cv”]O ponto que eu queria ilustrar mesmo é que vc não precisa de rollbacks se vc conseguir checar se vc pode fazer tudo que precisa fazer sem erros.
Até hoje ninguem deu um exemplo de onde isso seja impossivel ou impraticavel, mas de qualquer forma a gente implementou rollbacks no Prevayler 2 - tem pouca documentacao, mas da uma olhada nos sources ;)[/quote]
Te dou um seu exemplo cv: aplicações que envolvem transações distribuidas. A principio o prevayler não tem pq não poder participar, tirando o fato de não suportar XA (não tou falando besteira ne?), porém como é impossivel determinar localmente se a transação deve ser completada, rollback é indispensavel.
Moral da historia, prevayler, e a implementação de rollback dele, servem apenas para sistemas que usar 1-phase commit, com 2-phase commit não dá.
Esse é o único exemplo que eu consigo pensar também, ainda bem que não é um caso muito comum.
E essa sua incrivel conclusao se baseia em…?
Eh possivel quebrar essa afirmacao facilmente: o sistema de uma padaria grande (que apesar de simples, eh “comercial” e “profissional”, segundo a sua classificacao), cabe em RAM. Logo, a sua logica esta errada.
Pra exemplificar um pouco mais, o GUJ inteiro cabe em RAM, facil, e a gente realmente cogitou implementar ele usando o Prevayler (coisa que alias nao ta nem totalmente descartada ainda).
Se os sistemas com os quais vc trabalha movem volumes de dados grandes demais para que ele caiba em memoria de forma que o custo-beneficio fique razoavel, tudo bem, eh uma das limitacoes do Prevayler, e eh justamente a limitacao que traz todas as outras features dele. So nao venha com esse tipo de generalizacao besta, Oziel… eu sei que vc consegue fazer melhor
[quote=“cv”]
So nao venha com esse tipo de generalizacao besta, Oziel… eu sei que vc consegue fazer melhor ;)[/quote]
iiii !!
Deu até medo de postar alguma coisa aqui !! 
[quote=“javeloper”]iiii!!
Deu até medo de postar alguma coisa aqui!! :P[/quote]
O medo foi tanto que o primeiro instinto que vc teve foi clicar no Reply!? huehueuhe :D0
Foi mal se eu peguei meio pesado… mas espalhar conclusoes sem logica nenhuma como verdadeiras eh meio trash, ainda mais quando se trata de propaganda negativa sobre um projeto seu
Sem ofensas CV… E cade os moderadores do topico???
Minha conclusao nao e tao “besta” assim…
Entretanto, uma padaria grande, com certeza vai querer um sistema robusto e confiavel. No atual mercado brasileiro, nao da para confiar em hardware, principalmente Ching-Ling…
Armazenar os dados em memoria, e um problema serio… E fazer a persistencia em background e pior ainda…
No caso de uma padaria grande, eu ficarei com MySQL ou PostgreSQL… E nao Prevlayer…
Bom,vou começar a fazer um Terminal de Informações Acadêmicas inteiro usando o Prevayler…(tah certo,em projeto final o caráter é experimental,mas ainda assim vale…eh pra quase 100.000 alunos)
O número de consultas é sempre muito superior ao de inserts…(os alunos só alteram dados quando seus cadastros estão errados-raramente-e 2 vezes ao ano para escolherem as matérias q irão cursar,ou ofertas de emprego ou cursos-na verdade são poucos-).Acho o Prevayler uma excelente opção para essa situação!Veremos logo se estou certo(ou não).
Ok, e qual a relação disso com o prevayler?
Uma falha do hardware vai causar exatamente o mesmo resultado no oracle e no prevayler.
Ambos vão carregar a base de dados, reler seus transaction logs e aplicar as devidas correções. Dadas as suas devidas diferenças, eu não consigo verificar onde o prevayler falha em ser confiavel.
Alguem pode argumentar que um rdbms sobrevive a desastres catastróficos muito melhor que o prevayler, mas isso é uma classe de problema que o prevayler não trata e não cabe a ele tratar.
Concordo louds,e, cá entre nós,o problema mais grave,o risco de um cluster defeituoso mandar teus logs pro espaço,não é nada q um simples sistema em raid 1(espelhamento)não consiga resolver…
Olá
Vou tirar um pouco o foco dos últimos posts um tanto acirrados e voltar ao tema inicial da pasta.
Uma das ocasiões na qual é impossível usar prevayler é aquela onde por contrato precisamos armazenar logs de transações recuperáveis. Exemplos:
E mais: bancos são muito conservadores. Dificilmente um banco aceitará uma base de dados free typo MySQL ou PostgreSQL. Imagino que atualmente será uma tarefa hérculea convencer um Bradescão a aceitar o prevayler.
[]s
Luca
phew! Ate que enfim alguem resolveu tirar a conversa do caminho que so ia acabar levando a lugar algum. Valeu, Luca!
Concordo com a situacao que vc propôs, e, de fato, num sistema com varias camadas (remotas, pra complicar um pouquinho a coisa), o Prevayler nao eh uma ideia legal: nesses casos, 2PC comeca a se tornar importante, e o suporte do Prevayler a isso é bem rudimentar por enquanto. Mas nada impede que ele possa ser melhorado. A gente só não achou ninguém corajoso o suficiente pra tentar fazer algo desse tipo, então o código que tem hoje relacionado a transações é bem experimental, e roda em situações hipotéticas. Resumindo, fica difícil programar uma coisa que vc não vai precisar usar
Nao foi tao dificil assim nao
Pelo menos um banco q eu conheco usa Prevayler na intranet, para gerenciamento de documentos. E os requisitos dos caras são bem chatinhos, mas concordo na hora de gerenciar as partes onde se mexe mesmo com o bruto da coisa, talvez nem Oracle aguente… no Bradesco se usa assembly em muitas áreas do processamento de transações mexendo com flat-files dentro dos mainframes, pra dar um gás na performance…
oi pessoal,
valeu pelo esclarecimento.
Sem querer abusar da boa vontade de vocês, mas eu já tenho mais uma dúvida.
Se num sistema prevalente os objetos devem ser determinísticos, para qualquer entrada um método que possua esse objeto deve ter a mesma saída sempre.
Por exemplo, no caso de uma transação, se ao invés de usarmos o rollback usarmos exceções, as saídas não serão diferentes?
não sou nenhum defensor do rollback, apenas quero entender isto pois, a própria equipe do prevayler diz: se o rollback não é necessário por que gastar tempo usando-o?