Hibernate Efetivo: 6 dicas para não deixar sua app morrer

Hibernate EFETIVO
ERROS COMUNS E SOLUÇÕES

Tuesday, August 7, 2012

Eu estava me
perguntando quando de
fato o Hibernate foi
criado...


Eu estava me
perguntando quando de
fato o Hibernate foi
criado...
O “Boom” foi em 2003!

Luca Bastos

Quase uma década!
2012 - 2003 = 9


mas ainda hoje...


mas ainda hoje...
existem devs que
subutilizam o framework


mas ainda hoje...
existem devs que
subutilizam o framework

problemas de perfomance
e escalabilidade

e pra piorar...


culpam o Hibernate


culpam o Hibernate

A culpa é do Banco de
Dados!

Sérgio


é fácil culpar o que não se
conhece...


um SGDB mal conﬁgurado
pode ser o problema...


um SGDB mal conﬁgurado
pode ser o problema...

MAS na maioria das vezes o
problema está na SUA
APLICAÇÃO

tabelas sem índices

<3

consultas mal-feitas

<3 <3

muitos hits ao banco

<3 <3 <3

connection leaks

<3 <3 <3

connection leaks
memory leaks

<3 <3 <3

Não saber tirar
proveito framework


Hibernate Efetivo
6 dicas para não deixar
sua app morrer


@rponte


Fortaleza - Terra do Sol

#1
POOL DE
CONEXÕES


com certeza todos aqui
já ouviram falar...


mas nem todos dão a devida atenção...


até perceberem a app engasgando


ou até receberem um


ou até receberem um

org.hibernate.exception.Gener
icJDBCException: Cannot
open connection


daí percebem que não conﬁguraram o
o pool do Hibernate

hibernate.properties
hibernate.connection.driver_class=org.postgresql.Driver
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.connection.url=jdbc:postgresql://localhost:5432/myapp
hibernate.connection.username=postgres
hibernate.connection.password=1234


daí percebem que não conﬁguraram o
o pool do Hibernate

hibernate.connection.pool_size=30


a app volta a funcionar
bem por um tempo


e vão alocando mais conexões com o
tempo


hibernate.connection.pool_size=30

40

55

70

...


o pool PADRÃO do
Hibernate


que possui uma impl.
RUDIMENTAR


INFO DriverManagerConnectionProvider:64 - Using Hibernate built-in
connection pool (not for production use!)
INFO DriverManagerConnectionProvider:65 - Hibernate connection pool
size: 20


not for production use!

INFO DriverManagerConnectionProvider:64 - Using Hibernate built-in
connection pool (not for production use!)
INFO DriverManagerConnectionProvider:65 - Hibernate connection pool
size: 20


qual pool utilizar?


temos ótimas opções...


temos ótimas opções...

pools como c3p0 ou
commons-dbcp

o Hibernate já vem
com c3p0


conﬁgurando c3p0

hibernate.c3p0.min_size=5
hibernate.c3p0.max_size=20
hibernate.c3p0.timeout=1800
hibernate.c3p0.max_statements=50


ou melhor ainda...


podemos obter as conexões de um DataSource

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
! 
! <property name="driverClass" value="${jdbc.driverclass}" />
! <property name="jdbcUrl" value="${jdbc.url}" />
! <property name="user" value="${jdbc.username}" />
! <property name="password" value="${jdbc.password}" />
! 
! <property name="initialPoolSize" value="3" />
! <property name="minPoolSize" value="6" />
! <property name="maxPoolSize" value="25" />
! <property name="acquireIncrement" value="3" />
! <property name="maxStatements" value="0" />
! 
! <property name="acquireRetryAttempts" value="30" />
! <property name="acquireRetryDelay" value="1000" /> 
! <property name="breakAfterAcquireFailure" value="false" />
! 
! <property name="maxIdleTime" value="180" /> 
! <property name="maxConnectionAge" value="10" /> 
! 
! <property name="checkoutTimeout" value="5000" /> 
! <property name="idleConnectionTestPeriod" value="60" /> 
! <property name="testConnectionOnCheckout" value="true" />
! <property name="preferredTestQuery" value="SELECT 1+1" />
</bean>

Pool traz melhoria de
performance


Pool traz melhoria de
performance
mas não faz milagres


#2
lidando com
LazyInitialization
Exception


quando e por que acontece?


@Entity
class
NotaFiscal
{

…

@OneToMany

List<Item>
itens;
}


Percorrendo os itens de uma nota

NotaFiscal
nf
=
(NotaFiscal)
session.load
(NotaFiscal.class,
42);
List<Item>
itens
=
nf.getItens();


Hibernate executa 2 selects

NotaFiscal
nf
=
(NotaFiscal)
session.load(NotaFiscal.class,
42);

select nf.* from NotaFiscal nf
where nf.id=42
List<Item>
itens
=
nf.getItens();

select i.* from Item i
where i.nota_fiscal_id=42


a session do Hibernate foi fechada

Session
session
=

sessionFactory.openSession();

NotaFiscal
nf
=
(NotaFiscal)
session.load
(NotaFiscal.class,
42);

session.close();

List<Item>
itens
=
nf.getItens();
System.out.println("numero
de
pedidos:"
+

itens.size());


mas ao ler os itens da nota

Session
session
=


NotaFiscal
nf
=
(NotaFiscal)
session.load
org.hibernate.LazyInitializationException:
(NotaFiscal.class,
42);
failed to lazily
session.close(); initialize a collection -
no session or session was closed.
List<Item>
itens
=
nf.getItens();
de
pedidos:"
+

itens.size());


resolver parece fácil, certo?


fechar a session ao término do trabalho

Session
session
=


NotaFiscal
nf
=
(NotaFiscal)
session.load
(NotaFiscal.class,
42);

List<Item>
itens
=
nf.getItens();
de
pedidos:"
+

itens.size());

session.close();


Mas e quando estamos
trabalhando na Web?


NotaFiscalController.java
@Get("/notas/{id}")
public
void
view(Long
id)
{

NotaFiscal
nf
=
notaFiscalDao.carrega(id);

result.include("nf",
nf);

result.forwardTo("/notas/view.jsp");
}

view.jsp
<c:forEach
var="item"
items="${nf.itens}">

${item.produto.descricao}<br/>
</c:forEach>


NotaFiscalController.java
@Get("/notas/{id}")
public
void
view(Long
id)
{

NotaFiscal
nf
=
notaFiscalDao.carrega(id);

result.include("nf",
nf);

result.forwardTo("/notas/view.jsp");
}
LazyInitializationException
view.jsp
<c:forEach
var="item"
items="${nf.itens}">

${item.produto.descricao}<br/>
</c:forEach>


e agora? #comofas


e agora? #comofas

passa tudo pra
EAGER! ;D

Sérgio


@Entity
class
NotaFiscal
{

…

@OneToMany(fetch=FetchType.EAGER)

List<Item>
itens;
}


Hibernate executa 1 select

NotaFiscal
nf
=
(NotaFiscal)
42);

select nf.*, i.* from NotaFiscal
nf left outer join Item i on
nf.id = i.nota_fiscal_id
where nf.id=42


mas isso poderia gerar
uma sobrecarga...


mas isso poderia gerar
uma sobrecarga...

pois os itens da nota
não são necessários em
muitos lugares

lembre-se que ter os
relacionamentos como LAZY é
uma boa prática


como evitar LIE sem
modiﬁcar o relacionamento
para EAGER?


Open Session In
View


Servlet Filter
@WebFilter(urlPatterns="/*")
public
class
OpenSessionInViewFilter
implements
Filter
{

SessionFactory
sessionFactory;

@Override

public
void
doFilter(ServletRequest
req,
ServletResponse
res,

FilterChain
chain)
{

Transaction
transaction
=
null;

try
{

Session
session
=
sessionFactory.getCurrentSession();

transaction
=
session.beginTransaction();

chain.doFilter(req,
res);

transaction.commit();

}
finally
{

if
(transaction
!=
null
&&
transaction.isActive())
{

transaction.rollback();

}

}

}
}

o OSIV só evita LIE no
mesmo request!


anti-pattern?


#3
Second Level
Cache


Carregando uma nota por ID

NotaFiscal
nf
=
(NotaFiscal)
session.load
(NotaFiscal.class,
42);


Session

Banco de Dados


First Level Cache

Session

Banco de Dados


Session Session Session Session

Banco de Dados



Second Level Cache

Banco de Dados


First Level Cache


Second Level Cache

Banco de Dados



SessionFactory

Banco de Dados


Conﬁgurar é simples


#1 conﬁguramos o Hibernate

hibernate.cache.use_second_level_cache=true
hibernate.cache.region.factory_class=net.sf.ehcac
he.hibernate.EhCacheRegionFactory


#2 conﬁguramos as entidades

@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE)
class
Issue
{
@Id

private
Long
id;
private
String
descricao;
private
String
status;
@ManyToOne
private
Projeto
projeto;

@OneToMany

private
List<Comentario>
comentarios;
}


Caching Strategy

@Cache(
usage=CacheConcurrencyStrategy.READ_WRITE)

READ_ONLY

NONSTRICT_READ_WRITE

READ_WRITE


Caching Strategy

@Cache(

READ_ONLY Melhor performance


READ_WRITE


Caching Strategy

@Cache(

READ_ONLY

NONSTRICT_READ_WRITE Dados não críticos

READ_WRITE


Caching Strategy

@Cache(

READ_ONLY


READ_WRITE Modiﬁcações frequentes


ehcache.xml
<cache

name="br.com.triadworks.model.Issue"

maxElementsInMemory="10000"

eternal="false"

timeToIdleSeconds="1800"

timeToLiveSeconds="10000"

overflowToDisk="true"

memoryStoreEvictionPolicy="LRU"
/>


Como 2nd Level Cache
funciona?


2nd Level Cache não faz cache
das instancias das entidades


das instancias das entidades
somente dos valores
das propriedades


@Entity
class
Issue
{
@Id

private
Long
id;
private
String
descricao;
private
String
status;
@ManyToOne
private
Projeto
projeto;

@OneToMany

private
List<Comentario>
comentarios;
}


modelo conceitual do cache

Issue Data Cache
17 -> [ “Bug #1”, “ABERTA” , 1 ]
18 -> [ “Bug #2”, “FECHADA”, 2 ]
19 -> [ “Bug #3”, “ABERTA” , 1 ]



Issue Data Cache
17 -> [ “Bug #1”, “ABERTA” , 1 ]
18 -> [ “Bug #2”, “FECHADA”, 2 ]
19 -> [ “Bug #3”, “ABERTA” , 1 ]

não é uma árvore de objetos,
mas sim um "Map de Arrays"


das associações


@Entity
class
Issue
{
@Id

private
Long
id;
private
String
descricao;
private
String
status;
@ManyToOne
private
Projeto
projeto;

@OneToMany


private
List<Comentario>
comentarios;
}



Issue Data Cache
17 -> [ “Bug #1”, “ABERTA” , 1, [1,2] ]
18 -> [ “Bug #2”, “FECHADA”, 2, [] ]
19 -> [ “Bug #3”, “ABERTA” , 1, [3] ]


Devo cachear todas as
minhas entidades?


Com 2nd Level Cache tudo funciona bem
enquanto buscamos por ID...
session.load(Issue.class,
17);


Com 2nd Level Cache tudo funciona bem
enquanto buscamos por ID...
session.load(Issue.class,
17);

...mas e quando precisamos de uma
consulta um pouco diferente?
session

.createQuery("from
Issue
where
status
=
?")

.setString(0,"ABERTO")

.list();


#4
Query Cache


Query Cache faz cache do
resultado de uma query


Conﬁgurando Hibernate para
usar Query Cache

hibernate.cache.use_query_cache=true


Query Cache

session

.createQuery("from
Issue
where
status
=
?")

.setString(0,
status)

.setCacheable(true)

.list();


modelo conceitual do query cache

Query Cache

[“from Issue where status = ?”, [“ABERTA”]] -> [17, 19]


modelo conceitual do query cache

Query Cache

[“from Issue where status = ?”, [“ABERTA”]] -> [17, 19]

Query + Parâmetros IDs


por isso Query Cache SEM
2nd Level Cache não é de
muita ajuda


Utilize somente em consultas
que são executadas repetidas
vezes com os mesmos
parâmetros


#5
Select n+1


o campeão em prejudicar
a performance da
aplicação


Processando os itens de uma nota

NotaFiscal
nf
=
(NotaFiscal)
session.load
(NotaFiscal.class,
42);
processaItensDaNota(nf);



NotaFiscal
nf
=
(NotaFiscal)
42);

where nf.id=42

select i.* from Item i
where i.nota_fiscal_id=42


Processando os itens de varias notas

List<NotaFiscal>
notas
=
dao.listaTudo();
for
(NotaFiscal
nf
:
notas)
{

}


Hibernate executa n+1 selects

List<NotaFiscal>
notas
=
dao.listaTudo();


for
(NotaFiscal
nf
:
notas)
{

}

select i.* from Item i where i.nota_fiscal_id=?
...


são muitos hits no banco de
dados


são muitos hits no banco de
dados
mas podemos resolver
isso...


3 soluções


#1 EAGER ou join-
fetch


Utilizando FetchMode=EAGER

@Entity
class
NotaFiscal
{

…

@OneToMany(fetch=FetchType.EAGER)

List<Item>
itens;
}


Hibernate executa 1 select

List<NotaFiscal>
notas
=
dao.listaTudo();

select nf.*, i.* from NotaFiscal
nf left outer join Item i on
nf.id = i.nota_fiscal_id


antes de deﬁnir um
mapeamento global deste
tipo você precisa se
perguntar...

SEMPRE que uma nota é
necessária, todos seus
itens também são
necessários?


Utilizando Join Fetch

session

.createQuery("from
NotaFiscal
n

left
join
fetch
n.itens")

.list();


#2 batch-size nas
associações


É o meio termo entre
EAGER e LAZY


@BatchSize

@Entity
class
NotaFiscal
{

…

@OneToMany

@BatchSize(size=10)

List<Item>
itens;
}


Hibernate executa n/10+1 selects

List<NotaFiscal>
notas
=
dao.listaTudo();


for
(NotaFiscal
nf
:
notas)
{

}

select i.* from Item i where i.nota_fiscal_id
in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
select i.* from Item i where i.nota_fiscal_id
in (?, ?, ?, ?, ?)


@BatchSize também é
conhecido como:


conhecido como:

otimização de adivinhação cega
(blind-guess optimization)


conhecido como:

otimização de adivinhação cega
(blind-guess optimization)

ou seja, é um palpite

#3 FetchMode
SUBSELECT


SUBSELECT

@Entity
class
NotaFiscal
{

…

@OneToMany

@Fetch(FetchMode.SUBSELECT)

List<Item>
itens;
}



List<NotaFiscal>
notas
=
dao.listaTudo();


for
(NotaFiscal
nf
:
notas)
{

}

select i.* from Item i where
i.nota_fiscal_id in (select nf.id from
NotaFiscal nf)


Qual utilizar?


Qual utilizar?

depende

#6
Processamento
em lote


Imagine que temos que
importar 100k produtos para
o banco de dados


Session
session
=
sf.openSession();
Transaction
tx
=

for
(
int
i=0;
i
<
100000;
i++
)
{

Produto
produto
=
new
Produto(...);

session.save(produto);
}

tx.commit();
session.close();


em ~50k produtos nós
receberíamos um
OutOfMemoryException


por que?


Hibernate faz cache de todas
as instâncias dos Produtos
inseridos na Session


mas como melhorar?


Session
session
=
sf.openSession();
Transaction
tx
=

for
(
int
i=0;
i
<
100000;
i++
)
{

Produto
produto
=
new
Produto(...);

session.save(produto);

if
(i
%
100
==
0)
{

session.flush();

session.clear();

}
}

tx.commit();
session.close();


evitamos o OutOfMemoryException



Mas o processamento ainda
continua lento!



Mas o processamento ainda
continua lento!

Dá pra melhorar?


JDBC puro?


JDBC puro?

código de maxu!

Handerson Frota

StatelessSession


API mais baixo nível

próxima ao jdbc
sem 1st Level Cache

mapeamento básico sem 2nd Level Cache

StatelessSession
sem cascade
sem dirty-checking
Collections são ignorados

sem modelo de
sem interceptors
eventos

StatelessSession
session
=

sf.openStatelessSession();
Transaction
tx
=

for
(
int
i=0;
i
<
100000;
i++
)
{

Produto
produto
=
new
Produto(...);

session.insert(produto);
}

tx.commit();
session.close();


menos consumo de memória
e mais rápida!


dá pra melhorar?

Yuri Adams

menos consumo de memória
e mais rápida!



hibernate.jdbc.batch_size=50


CONCLUSÃO


Foi apenas a ponta o iceberg!


cada uma destas dicas são simples,
mas requerem mais estudo


cada uma destas dicas são simples,
mas requerem mais estudo
pois depende do projeto


um DBA certamente pode ter
ajudar em muitos cenários


Hibernate não é seu inimigo,
deixem de #mimimi


Rafael Ponte
rponte@triadworks.com.br


Hibernate Efetivo: 6 dicas para não deixar sua app morrer

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (18)

Más de Rafael Ponte

Más de Rafael Ponte (20)

Hibernate Efetivo: 6 dicas para não deixar sua app morrer