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:

1. A proporção quantidade de dados X ram se dá como?

2. 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…

“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 ;)

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

“cv”:

So nao venha com esse tipo de generalizacao besta, Oziel… eu sei que vc consegue fazer melhor ;)

iiii !!
Deu até medo de postar alguma coisa aqui !!

“javeloper”:

iiii!!
Deu até medo de postar alguma coisa aqui!! :P

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:

• uma aplicação bancária construída em várias camadas com as transações sendo desfeitas em caso de falha em uma das camadas.(localizadas em servidores remotos)
• Aplicações com transações tarifadas tb em várias camadas.

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?

“Determinístico” diz que, se o estado do sistema for tal, e o método fazBesteira() for chamado, e ele jogar uma exceção, sempre que o sistema estiver no estado “tal”, o fazBesteira() deve lançar uma exceção.

Ou seja, não quer dizer que o método deve sempre retornar, mas sim que o método tem sempre que produzir o mesmo resultado dado o mesmo estado no sistema.

Isso se faz necessário pq, na recuperação dos logs, os métodos são executados de novo - daí também a limitação de se usar I/O ou depender do relógio do sistema nas Transactions

Talvez exista algum jeito de tornar o Prevayler mais confiavel, nesse sentido. Uma das maneiras que eu consigo imaginar aqui seria fazer o Prevayler logar numa fila JMS de entrega garantida (quem ja conseguiu fazer o MQSeries funcionar sabe do que eu tou falando, o bicho entrega a mensagem mesmo que caia uma bomba no datacenter)… ou, sei lah, gravar o txlog num arquivo texto (assim, ele pelo menos pode ser corrigido por um humano na pior da pior das hipoteses ;))

louds… Se ocorrer uma falha de software ou de SO, o Oracle é conhecido como “UNBREAKBLE”… Eu ja presenciei isso varias vezes…

E sem paixoes, eu nao colocaria um sistema critico rodando em Prevayler… Prefiro um RDBMS mesmo… ORACLE, DB2, SQLServer, etc…

Entretanto, talvez o sistema do Iron funcione legal e tenha qualidades sitemicas razoaveis usando o Prevayler, por ter muitas consultas e poucas atualizacoes…

E gente… Estamos discutindo o sexo dos anjos…

[]'s

Nao tem magica no que o Oracle faz. Ele grava tantos checksums em tantos lugares quantos forem possiveis. Da pra fazer um ObjectOutputStream que faca isso tambem (grave 3 vezes cada byte, em 3 arquivos identicos, mas localizados em particoes diferentes, e no fim de cada serie ainda ponha um checksum gigantesco, pra ser bem paranoico :D). Ou seja, a sua ideia de unbreakable eh meio subjetiva

“ozielneto”:

louds… Se ocorrer uma falha de software ou de SO, o Oracle é conhecido como “UNBREAKBLE”… Eu ja presenciei isso varias vezes…
[]'s

Eu falei desastres catastróficos Oziel, não falhas comuns. Quanto ao oracle, não posso questionar muito, maioria do problemas que eu já vi são culpa do people-ware.
Porém voce estava comparando com mysql e postgresql, produtos na mesma “faixa de preço” do prevayler. Eu já vi ambos bancos crashando sem motivo, falhando e perdendo transações commited por uma simples falta de luz e por ai vai.

O problema do prevayler é a serialização do java, que não foi feita para ser resistente a desastres. Usar 1 fila JMS seria 1 boa opção, mas existem soluções mais leves para aumentar a confiabilidade dos txfiles.

Olá

Apenas para corroborar o Louds.

Há menos de 2 meses na empresa em que eu estava um nobreak mal dimensionado ou sobrecarregado pifou após uma brevíssima queda de luz. A falha foi tão breve e tão localizada que ninguém percebeu no resto da empresa. Nunca soubemos onde foram parar as transações perdidas depois o último backup porque o AIX não bootava mais e precisou ser reinstalado. Detalhe: não funcionou a instalação no modo preservation, pois o Oracle passou a dar conflito em uma maldita lib. Depois de muito googlar, buscar suporte e muitas outras tentativas, a solução foi reinstalar TUDO.

“Only Murphy is UNBREAKBLE”

[]s
Luca

Opa…

Tava lendo os post e acho demais querer comparar o Prevayler com o Oracle não que não possa ocorrer mas tipo no Oracle é um investimento porrada em cima dele…
E sobre esse esquema de “UNBREAKBLE” o banco Oracle é sim muito seguro e tal…mas quando o tio Larry lançou o desafio para os hackers um ecpecialista em segurança apontou diversas falhas no banco…e esses dias mesmo a Oracle adivertiu para uma tremenda falha de segurança. Bom quem tem acesso ao meta link deles sabe o quanto de path e correções que saem até uma versão do banco ficar estável.

[]'s

A intenção do Prevayler não é substituir o Oracle…é só a de ser uma alternativa…Por ser simples,seus erros(ou prováveis problemas) são muito mais rastreáveis do q uma puta falha do Oracle…vc pode prever o q o sistema Prevalente não suportará e tomar providências qto a isso…num sistema usando Oracle,rola uma certa autosuficiência(ou seria negligência?)de algumas empresas…tipo -ah,o Oracle suporta!Depois eh um salve-se quem puder pagando 20.000 para um DBA diagnosticar uma falha(por vezes tola como a do NoBreak citado pelo Luca),e outros tantos para repará-lo…aliás,só por curiosidade,qto tah uma licença Oracle?