Controle Transaciona Programatico

OO no mundo real: evite vazamento de conexões com controle transacional programático

No último Javou (evento da JavaCE) o prof. Alexandre Martins comentou na sua palestra que um dev junior conseguiu derrubar por alguns minutos o sistema de previdência social da Dataprev. Estou falando do principal sistema da empresa… muito louco não?

Sabe como? Ele esqueceu de colocar essa linha de código aqui:

conexao.close();  // fecha conexão com o banco

Simmm! Ele esqueceu de fechar uma conexão com o banco de dados! Se você não sabe, uma conexão é um recurso muito caro e, para piorar, é muito limitado; todo banco tem um limite de conexões que podem ser abertas, se esse limite estourar já era, a aplicação não consegue mais conversar com o banco!

(Eu nem culpo esse dev junior, até porque eu já fiz algo parecido em alguns sistemas… mas não conta pra ninguém, tá?)

Mas como ele poderia ter evitado?

A boa prática diz que todo recurso caro que for aberto deve sempre ser fechado quando não for mais utilizado. Uma boa maneira de fazer isso é através do bloco try-catch-finally do Java:

Connection conexao = null;
try {
    conexao = ConnectionFactory.getConnection();
    // logica de negócio

} catch (SQLException e) {
    // trata erro
} finally {
    conexao.close(); // fecha conexão com o banco
}

O problema é que repetir esse código em todo o sistema é muito frágil, cedo ou tarde alguém esquece e termina com o sistema fora do ar. Aí já viu né, é justa causa…

E se eu te dissesse que tem uma maneira mais elegante de resolver isso usando OO? É o que chamamos de controle transacional programático e traz diversos benefícios para qualquer sistema, entre eles a garantia que toda conexão com o banco é fechada!

Pra te ajudar a entender do que estou falando, eu bloguei sobre o assunto:

[Post] Controle Transacional Programático em Sistemas Legados

Após ler esse artigo eu te garanto que você vai levar o controle de conexões e transações na sua aplicação mais a sério, seja seu sistema legado ou mais moderno com JPA e Hibernate.

2o Mau Habito Dos Desenvolvedores JSF

Método getter invocado múltiplas vezes?

Você sabia que uma simples consulta ao banco de dados colocada no método errado do seu managed bean pode tornar suas páginas 10x mais lentas?

Entre 2008 e 2014 eu palestrei em diversos lugares do Brasil sobre os 10 maus hábitos dos desenvolvedores JSF, e sem dúvida um dos problemas mais comuns que encontrei durante estas palestras conversando com profissionais, em consultorias e treinamentos foi o 2o mau hábito: colocar lógica cara em métodos getters.

Provavelmente você já caiu neste 2o mau hábito ou conhece alguém que tenha caído, de qualquer forma, podemos simplificá-lo com um simples trecho de código. Por exemplo, um problema grave pode estar num simples método getter:

public List<Produto> getProdutos() {
    return this.dao.lista(); // lista produtos do banco
}

Apesar deste método parecer inofensivo ele pode tornar sua página até 10x mais lenta para abrir no navegador! Caso duvide ou queira entender por que ele pode ser tão perigoso para sua aplicação, eu recomendo a leitura do meu novo post:

>> JSF: Não coloque processamento caro em métodos getters

Colocar consultas dentro de getters é tão perigoso que, na maioria dos casos, além de impactar diretamente na aplicação Java ele impacta no banco de dados pois este é bombardeado com inúmeras consultas.

E aí, o que achou da dica?

Deixe seu comentário, e se tiver algum amigo que curte meter consultas em getters por comodidade, eis a chance de convence-lo do contrário.

Relatorios PDF com JasperReports

JasperReports: gere relatórios PDF na sua aplicação Web

Não sei você, mas eu sempre tive uma grande dificuldade com a API do JasperReports para gerar relatórios em PDF. Novo projeto significa reaprender a API. E acreditem, não tem como decorar um código que você praticamente escreve uma única vez e nunca mais olha.

Eu não gosto de simplesmente colar um código de um projeto em outro sem antes entender o que aquele código faz e como funciona. Por exemplo, para gerar relatórios nas minhas aplicações é comum ter um código semelhante a este:

// parametros
String jrxml = "/relatorios/todos-cursos.jrxml";
Map<String, Object> parametros = new HashMap<>();
Connection conexao = new ConnectionFactory().getConnection();

// gera relatorio pdf
GeradorDeRelatorios gerador = new GeradorDeRelatorios(conexao);
File pdf = gerador.geraPdf(jrxml, parametros);

// escreve na saida do response
Files.copy(pdf.toPath(), output);

O código é bem simples, não é? Isso porque toda a complexidade da API do JasperReports está encapsulada dentro da classe GeradorDeRelatorios. Todos os detalhes estão dentro dela e do seu método geraPdf. Dentro deste método existem 3 passos importantes para gerar relatórios em PDF, os relatórios que você desenhou com o iReport.

Para entender os 3 passos e o que realmente importa na API do JasperReports eu recomendo você ler meu novo post no blog da TriadWorks:

>> Como gerar relatórios PDF na Web com JasperReports

A verdade é que eu escrevi esse post para NUNCA mais esquecer como a API funciona e como posso tirar proveito dela. Ainda no post, eu aproveito para ensinar como disponibilizar seu PDF para download na sua aplicação Web.

E ai, como você implementou sua classe para gerar relatórios?