Normalmente, problemas como esse acontece quando se tem um programador ou analista desavidado, que acha que o Hibernate é o "rei da cocada preta"; que só basta criar as classes e os seus respectivos arquivos de mapeamente que está tudo tranqüilo.
Sem dúvida, ao criar as classes e mapeá-las já é suficinete para trabalhar com Hibernate. Entretanto, como é feito essa modelagem de classes é o que diferencia um profissional de um pára-quedista. Existe muitas maneiras de otimizar o mapeamento das classes. Um estudo detalhado desta modelagem se faz necessário para obter um ganho de performance significativo. Tomar os devidos cuidados com relação à identidade de objetos é de suma importância para não vir a ter decepções no futuro; saber modelar a cardinalidade e a navegabilidade entre as associações de classes também é primordial. De repente, uma associação bilateral pode nos levar a resultados desastrosos, sem necessidade. O problema que o autor deste artigo está enfrentando, eu também passei, usando Oracle, quando estava iniciando os trabalhos com Hibernate. A diferença é que pesquisei bastante antes de sair falando besteiras a respeito da framework. Parto do princípio de que se dentre milhares de pessoas que utilizam Hibernate (ou NHibernate), apenas uma, duas ou até dez pessoas falam asneiras desta framework, o problema está no profissional e não na framework. Contudo, o interessante é que pessoas como essa conseguem convencer, com argumento fúteis como os apresentados aqui, apenas pessoas de seu mesmo nível intelectual ou de nível intelectual inferior ao seu. Está claro neste artigo que o autor não conhece a maneira com que o Hibernate trabalha (sequer consegue entender o código-fonte dessa framework), deve ser um analista que não sabe os verdadeiros conceitos de modelagem de negócio e não tem cultura nem para pesquisar em livros de primeira linha. Comentários como estes não merecem credibilidade por parte de pessoas com nível mais elevado do que o deste autor. Ele seque merece assinar como analista e deve sentir vergonha de se dizer um. Por fim, termino alertando de que o Hibernate, assim como outras frameworks (Linq, por exemplo), é um facilitador e não uma solução para os problemas dos ignorantes que se aventuram na análise e desenvolvimento de sistemas como este autor. CONHECER a intimidade da framework á o ponto crucial para iniciar os trabalhos com ela; caso contrário, problemas desse tipo ocorrerão não somente com PostgreSQL, mas também com qualquer outro banco-de-dados relacional. Fico a imaginar como este autor se sairia tendo de usar um banco-de-dados como o Caché, DB4O, ou qualquer outro banco-de-dados orientado a objetos. Um forte abraço a todos Denis Villegas wrote: > > Bom dia Pessoal, > > Estou com um problema no postgres aqui na empresa, tem umas querys que > estão consumindo o recurso do servidor, e sua performance caiu muito, > tanto que esta ocorrendo diversos timeouts, estou desconfiado de umas > rotinas do Hibernate, cujo o framework é utilizado pela equipe de > desenvolvimento. > > fiz um monitoramento e cheguei na seguinte analise: > Esses são as querys mais utilizadas: > > tempo(ms) quantidade tablespace(usuario) comando > 9996.995 128271 nextproddb(portal) EXECUTE <unnamed> [PREPARE: create > local temporary table HT_promotion_rule (id int8 not null) on commit > drop > 9967.797 1245 nextproddb(portal) EXECUTE <unnamed> [PREPARE: create > local temporary table HT_promotion_prize (id int8 not null) on commit > drop > 6575.679 793 nextproddb(portal) EXECUTE <unnamed> [PREPARE: select > promotionp0_.id as id32_, promotionp0_.creation_time as creation2_32_, > promotionp0_.delivered as delivered32_, promotionp0_.msisdn as > msisdn32_, promotionp0_.visible as visible32_, promotionp0_.enabled as > enabled32_, promotionp0_.reminder_sent as reminder7_32_, > promotionp0_.wappush_accepted as wappush8_32_, promotionp0_.rule_id as > rule9_32_, promotionp0_.expiration_time as expiration10_32_, > promotionp0_1_.delivered_items as delivered2_33_, > promotionp0_1_.number_of_items as number3_33_, > promotionp0_1_.promotional_category_id as promotio4_33_, case when > promotionp0_1_.id is not null then 1 when promotionp0_.id is not null > then 0 end as clazz_ from promotion_prize promotionp0_ left outer join > category_prize promotionp0_1_ on promotionp0_.id=promotionp0_1_.id > where promotionp0_.enabled=true and promotionp0_.reminder_sent=false > and promotionp0_.rule_id=$1 and promotionp0_.creation_time<$2 > 8815.257 397 nextproddb(portal) EXECUTE <unnamed> [PREPARE: update > promotion_rule set last_reminder_sent_time=$1 where (id) IN (select id > from HT_promotion_rule) > 4759.379 147 nextproddb(portal) EXECUTE <unnamed> [PREPARE: drop table > HT_promotion_rule > 5512.508 137 nextproddb(portal) EXECUTE <unnamed> [PREPARE: select id > from portal where id = $1 for update > > Gostaria de tentar otimizar esse tempo de 10s para a criacao de uma > tabela temporaria, alguem ja passou por algo semelhante e poderia me > ajudar a achar uma solucao? > > Fico no aguardo > > Obrigado > > Denis Hoffmeister Villegas > Analista de BI > Desenvolvimento > Tel: (11)3191-0200 R293 > Cel: (11)9282-2954 > SupportComm S.A. > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- View this message in context: http://www.nabble.com/Performace-baixa-com-Hibernate-tp14953369p16703405.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
