Re: Gerenciamento de transações. Porque não no DAO?

Programação Arquitetura
#41

[quote=Taz][quote=louds]
Cara, segurança definida no J2EE é muito, muito ruim. Qualquer coisa que não seja ‘área protegida + form de login’ não existe padrão, você é obrigado a utilizar extensões proprietárias. O clássico exemplo de implementar login programático na aplicação continua impossivel de forma padronizada.[/quote]

Acho que não. Autenticação é um dos aspectos de segurança (e talvez o mais simples!!!) tratados na J2EE. :wink:
[/quote]

Bom, então me mostra como faço para implementar autenticação programática com j2ee 1.4? Não vou nem falar de autorização, pq o modelo é tão ruim que não permite, por exemplo, definir políticas de acesso por instância. Resumindo, o modelo de autenticação e autorização não é nenhum pouco plugavel ou extensivel.

[quote=Taz]

Load balancing é muito melhor feito por uma solução de hardware ou um software especializado como o PLB. Clustering depende muito da arquitetura do projeto, como a maioria dos sistemas que trabalhei eram share-nothing, não utilizamos nada de especial. No resto o máximo que usamos foi um cache distribuido.

[quote=Taz]

Negativo, toda migração de versões/fornecedores é um inferno pelos seguintes motivos:

:arrow: A spec possui partes não especificadas, ou mal especificadas.
:arrow: Containers diferentes, bugs diferentes.
:arrow: Ninguém desenvolve aplicação J2EE, todo mundo desenvolve J2EE implementação xyz.

Moral da história, aplicações J2EE são muito mais facilmente portaveis que uma escrita em C++ e DCOM, por exemplo, mas não são a panaceia para o assunto.

#42

O assunto já perdeu o foco. Portanto, se vc tem dúvidas abra outros tópicos. Estou aqui para ajudar as pessoas e, com isso, tb aprender. Não estou aqui para me envolver em disputas de egos.

Existem pencas de artigos, livros e gurus que defendem a abordagem J2EE (Até Rod Jonhson, um grande opositor da J2EE, defende EJB como uma opção!!!). Se vc quer reinventar a roda, essa é uma decisão sua. Esteja preparado para adotar o lado “programático” das coisas e implementar infra-estrutura.

Se não usou é porque leu isso em algum lugar e foi convencido. Cite as fontes. :wink:

#43

Não lemos coisa alguma. Não existiu convencimento. Usamos simplesmente aquilo que melhor solucionava o problema.

Clustering, por exemplo, é a uma das coisas mais raras de você encontrar em qualquer empresa, pois implica em Single System Image. A norma são server farms com load balancers, uma arquitetura que normalmente escala muito mais.

#44

Eu não li essa discussão toda então não sei do que vocês estão falando. Mas você falou alguns conceitos que eu ainda não entendo bem. Sem querer abusar da sua boa vontade queria esclarer algumas dúvidas com você louds ou qualquer outra pessoa que tenha conhecimento sobre.

:arrow: Clustering então pelo que entendi sempre requer replicação de dados? Ou seja, Clustering é quando precisamos de confiabilidade?

:arrow: Eu pensava que balanceamento de carga já era Clustering. Pelo visto então não é!?!

:arrow: Eu trabalhei num sistema EJB que foi colocado em cluster, eu não participei dessa tarefa porque nesse projeto trabalhei apenas como programador e já existiam os budas do JBoss que fizeram essa tarefa. Lembro-me de ter perguntado como eles fizeram essa clusterização(como se eu fosse entender, mas perguntei :shock: ) e lembro do cara ter me respondido que colocou numa maquina a parte de venda e outra a parte de fechamento de caixa(simplificando as coisas). O sistema era apenas um EAR. Isto parece mais com balanceamento de carga então? Será que ele colocou duas maquinas cada uma com o mesmo EAR e faz o balanceamento de carga entao?

:arrow: Tem como explicar melhor esses conceitos Single System Image,farms, load balancers.

:arrow: Como o JBoss(ou um sistema EJB em geral se não existe diferença entre servidores diferentes) implementa Clustering?? Isso na verdade só funcionaria para SessionBeans?

:arrow: O pagina de pesquisa do Google é o sistema em Clustering mais famoso que existe, que tipo de cluster esses fdp estão falando(essa se você não souber eu perdoo) ?

Vlw :wink:

#45

[quote=louds]

Quanto a trocar de AS, esse teu argumento é brincadeira, nunca vi a migração de qualquer aplicação de media complexidade entre AS diferentes ser menos que um INFERNO. Normalmente já um problema enorme trocar a versão, de fornecedor então…[/quote]

Olha, o pessoal que migrou de JBoss <-> WebSphere disse q deu um pouco de trabalho, mas não foi tão caótico assim…

#46

e o pessoal do TheServerSide roda a aplicação do portal em 4 ou 5 app servers ao mesmo tempo (faz tempo que li, agora não tenho certeza)

#47

Bem lembrado Urubatan. Você chegou a ver algum deles falando do inferno que era? A primeira versão usava o core patterns do começo ao fim, e eles tiveram uma penca de problemas:

:arrow: Não tinha como usar CMP, apenas BMP funciona quando vc tem AS diferentes.
:arrow: Devido a arquitetura da aplicação, eles não implementaram edição de posts.
:arrow: Eles falavam que no geral a aplicação era um inferno de manter rodando.

Mas não vale muito já que ninguém vai fazer isso em produção, não vai, por exemplo, ter WebLogic falando via EJB com OC4J e se ferrar pq um desses dois não tem a mesma semântica em transações distribuidas.

O TSS hoje é feito com Tapestry e JDO, tanto pelos pobres EJBs de antes.

Microfilo, o povo migrou uma aplicação que tinha montes de EJBs que faziam tudo quanto é coisa mirabolante.

Isso me lembra de um projeto que eu quase embarquei em 2004, o povo tava migrando de versão do AS, depois de 2 meses de trabalho ajustando e testando o sistema inteiro, descobriram que um connector simplesmente não funcionava naquela versão que seria usada.

Hempx, lê o livro de Sistemas distribuidos do Tannebaum, lá tem resposta para quase todas as suas perguntas.

#48

Clusterização é algo muito comum por aí, até pq os ASs tornam ela muito fácil de ser implementada. O problema é que alguns desenvolvedores enxergam requisitos extraterrenos :shock: na hora de gerenciar transações e partem para soluções independentes… Afinal, que credibilidade têm fornecedores de produtos J2EE como IBM, JBoss e BEA? Eles não sabem nada de Java para mundo corporativo, não eh?

Hempx,

Não precisa ler o livro do Tannebaum para responder de maneira simples suas dúvidas. Mas, se vc quiser detalhes, sempre vale a pena, é claro… :wink:

A clusterização pode tanto ocorrer na camada de dados (recurso do BD) quanto na de processos (recurso do AS). Obviamente, se ela ocorrer nas duas seu sistema pode ser considerado mais tolerante à falhas e mais confiável. Mas tudo tem um custo, e este é o de atualizar as cópias de dados e/ou de processos em seu cluster.

Uma aplicação que contém o componente X em um servidor A e o componente Y em outro servidor B, rodando de maneira independente e separada, só pode ser considerada clusterizada se o AS estiver configurado para transferir a carga de A para B e vice-versa caso um deles caia. A IBM chama isso de nó (node) na plataforma Websphere. Um nó pode ter 1, 2, 3, n máquinas. Dessa maneira a clusterização também resolve o problema do balanceamento de carga (load-balancing). Um Case Study muito comentado pela IBM é o do eBay (um site com 65 milhões de usuários, 18000 categorias de produtos e que realiza 800000 transações por minuto)

“In September 2001, eBay went on a major software revamp to improve its site availability and make it more dynamic and interconnected. After reviewing more than 20 vendors, the company finally opted for IBM and its WebSphere application server and began to put in place its ‘V3’ application architecture. eBay also revamped its server-side application development architecture to support the Java 2 Enterprise Edition (J2EE)[3] and Enterprise JavaBeans[4] The company replaced a C++[5] object framework that required a lot of structural programming. Though the C++ environment was more flexible than Cobol, it couldn’t compete with J2EE, which was becoming the de facto application development framework. J2EE’s objects could handle a much higher level of abstraction than C++. The new applications were more widely distributed, running across multiple machines (both Windows and Solaris) and relied on data-dependent routing, which utilized server cache[6] more efficiently.” (http://icmr.icfai.org/casestudies/ebay%20IT4.htm)

Outras fontes:
http://www-304.ibm.com/jct03001c/services/learning/us/pdfs/onsite/ebaybrief.pdf
http://investor.ebay.com/news/20010906-57994.cfm?ReleaseID=57994&FYear=

eBay powered by J2EE!!! Precisa falar mais alguma coisa?

#49

Olá

Taz, uma dúvida pois estou um tanto desatualizado com a plataforma Websphere > 4.0. Antigamente a IBM vendia um monte de coisas não JEE para suportar o JEE do Websphere e não sei se isto mudou. No exemplo que você citou bastou comprar o Websphere ou foi necessário HACMP (High Availability Cluster Multiprocessing) e MQseries (para o HACMP)?

[]s
Luca

#50

Não conheço esse HACMP. Mas, quanto ao MQ Series, ele foi rebatizado como “Websphere MQ”.

http://www-306.ibm.com/software/integration/wmq/support/

Parece ser uma estratégia de marketing da IBM o agrupamento das soluções para desenvolvimento debaixo do guarda-chuva Websphere.

#51

Olá

Citei o HACMP porque antigamente a IBM não parecia confiar muito só no Websphere para cluster e preferia sua solução própria (que parece muito boa).

Fazer cluster com o JBoss é brincadeira de criança. Só não sei como se comporta em ambiente de produção exigente. Com o Websphere também era muito fácil. O problema é que o Websphere às vezes (raro mas acontecia) dava uns paus meio do nada. Não sei como andam as versões recentes.

Weblogic nunca usei. Aliás, esta semana ouvi no Theserverside, uma entrevista do Bob Pasker, que é um dos maiores especialistas em transações com mais de 25 anos de experiência. Ele fundou a Weblogic que depois foi vendida a BEA e hoje tem a Azul Systems que vende um clusterzinho de 384 processadores. Vale a pena ouvir. O link está em:
http://www.theserverside.com/talks/index.tss

[]s
Luca

#52

Me falaram e ja li nesse forum quem um erro que muitos cometem é colocar no DAO o gerenciamento de transações …

Nao consigo ver o que existe de errado nisso:

Produto prod = new Produto() ;
prod.setNome("Produto teste") ;
DAOProduto daoProduto = new DAOFactory().getDAOProduto() ;
daoProduto.save(prod) ;
daoProduto.commit() ;

no meu caso, não uso DAOs sigleton e não uso ThreadLocal, cada dao pega uma sessão e faz oq tem q fazer …

Me falaram p/ colocar o controle de transaçoes em outra camada da aplicação …

mas aonde? Algo concreto …

i pq assim não é aconselhavel?

#53

Isso eu entendo …

oq faço, não sei se eh certo, eh colocar algo do tipo no save do meu DAO:

	public void save(Entidade e) {
		Transaction tx;
		try {
			tx = this.session.beginTransaction();
			this.session.save(e);
			tx.commit() ;
		} catch (Exception e) {
			tx.rollback();
		}        
	}

é certo isso?

e se eu precisar ter o controle da transação ??

aonde eu colocaria isso?

numa aplicação web, filtros p/ controlar as transações eu concordo e uso quando estou trabalhando com ThreadLocal…

mas e p/ aplicações desktop?

#54

Gostei da ideia de criar um TransactionManager ou algo do tipo porem, quando não uso threadlocal e sim pego uma sessão do pool, como controlo se não dentro do DAO??

Gosto da ideia de ThreadLocal mas acho estranho pois ao meu ver você joga no lixo o pool de conexões (quando se usa um) …

não entendi!!! :?

quando vc der um run() vai disparar a thread certo? logo depois vc da um commit(), mas quem garante que eu terminei a execução da minha thread? desculpem minha ignorancia … hehehe…

Entendi a ideia de tirar o controle do DAO, porem não sei como fazer quando não uso ThreadLocal …

posso criar um TransactionManager que recebe um tipo DAO e uma sessão referente a ele e eu controlo a transação apartir dai … (pensei agora)

pode ser util pois quando eu tiver diversos DAOs e diversas transações, consigo manipula-las em um lugar só …

mas mesmo assim me cheira a gambiarra …

Usando ThreadLocal p/ controlar as transações eh tranquilo …
mas quando não uso ThreadLocal e sim uso uma sessão (vinda do pool) p/ cada DAO?

#55

[quote=louds]noel,

ThreadLocal não elimina o uso de pool, apenas elimina o passa-passa de objetos entre os varios layers da aplicação. Com TL, eu faço +/- assim:

try {
  threadLocal.put(pool.getConnection());
} finaly{
 ((Connection)threadLocal.get()).close();
  threadLocal.put(null);
}

Quanto a Runnable, você tá confundindo a interface Runnable com a classe Thread. Usar a interface não implica em criar threads.

Veja que se você usa uma conecção por DAO, tuas operações não são transacionais, afinal todos precisam todas usar a mesma conecção.

[/quote]

Com relação ao Runnable me abstenho tamanha a minha ignorancia …

e com relação a ThreadLocal, tudo resolvido, entendi … hehehe …

DAO e Transações não da certo, estou convencido … hehehe …

mas ficou uma duvida sobre ThreadLocal …

qualquer um pode pegar a sessão q eu coloquei na ThreadLocal?

#56