A questão do FAT me agrada, vi alguns exemplos e realmente me parece muito bom, principalmente no sentido de empacotar o Web Server no JAR
Eu realmente tenho essa preocupação, tanto que estou pensando em deixar o Hibernate com as sua funcionalidade principais apenas nos cadastros em em algum ponto ou outro (ainda discutível), mas no resto do sistema utilizar as StatelesSession, somente para facilitar.
isso e uma falacia.
se o hibernate é um gargalo, isso vai aparecer se vc executar um teste de performance + um profiler decente. e ai vc configura o mesmo decentemente. se Lazy não é beneficio então basta não usar.
acessar um banco de dados é uma forma de I/O e temos um delay devido a natureza do mecanismo de transporte pela rede, fora toda a questão de replicação, queries paralelas, dados normalizados, etc.
dificilmente o problema é o hibernate em si. muito provavelmente é a arquitetura decidida por um comitê que não foi desenhada para performance em algumas operações, o que é bem comum quando o povo desenha o banco de dados primeiro e a camada web passa a ser um “detalhe” ( e tem aquela famigerada sessão de “cadastros basicos” ou “vamos inventar como cadastrar pessoa fisica e juridica de uma forma diferente dessa vez”).
meu testemunho: Hibernate em Dynamic Creative Optimization tendo que responder milhares (worst case) de requests por segundo muito rapido (ou a propaganda não aparecia, e ninguem recebia $), eu acho que o problema não na ferramenta - e sim de não saber configurar ou usar. ah eu tinha umas partes Lazy também. detalhe que nós tinhamos monitoria em tempo real e rolava alerta quando algo demorava demais - muitos sistemas, principalmente corporativos, não tem nada disso.
eu lembro de um caso de uma operadora de telefonia onde uma parte do site redirecionava pra uma outra parte ( de pagamentos ) e frequentemente dava algum erro ( estilo interno 500 ) na cara do cliente. ai as duas equipes iam conversar e a outra parte não sabia lhufas do que acontecia ( mas negava os problemas ). chegaram ao ponto de alguem simular centenas de pagamentos em um dia pra fazer uma estatistica e tirar print screen de cada erro - e ainda assim a outra parte negava qualquer incidente E virou um problema politico.
minha visão é que existe toda uma classe de sistemas web desenhadas de forma muito ruim, imitando algo que deu certo na decada passada e que não se atualizou pro século XXI por falta de conhecimento e dominio do idioma inglês - quando não rola um overengineering/BDUF (nesse cenario talvez o proprio uso de java poderia ser questionado), e isso é diretamente relacionado aos interesses financeiros por tras do projeto.
agora culpar o Hibernate ou qualquer outra biblioteca é ridiculo - tem quem tenha desenvolvido o proprio driver de banco de dados por que ISSO q era o gargalo (e eu inclusive ja fiz isso, mas em outro contexto que não java).
eu ate diria mais: o programador web medio não tem experiencia com performance pois ele nem sempre precisa - vide a galera que salva imagem em banco de dados.
meus dois centavos
Mas o público alvo do Hibernate é esse. Claro, um programador com experiência em performance de banco de dados pode fazer miséria com Hibernate, assim como pode fazer com stored procedures, mas não é pra eles que a ferramenta foi criada, e sim para desenvolvedores de aplicações front-end que não deveriam precisar saber sobre performance de banco de dados.
Numa aplicação HTTP para um banco de dados, é só nao usar lazy, nao usar session com cache, …, opa, pra quê o Hibernate está sendo usado então? Por opção pessoal para seguir modelagem OO? Quanto a isso ok, cada um com suas escolhas.
Acho que com relação ao acesso a base está tranquilo.
Mas queria uma outra opinião de vocês, comecei a fazer a parte de infra estrutura, e para alguns processos do sistema, gostaria que eles continuassem em execução mesmo quando o usuário se desconectasse por qualquer motivo. Então criei uma lista com as Threads que estão cuidando do processo e um gerenciador que fica monitorando se o processo acabou e se já deu o tempo de TimeOut, para então limpar esse objeto da memória.
Vocês têm alguma sugestão com relação ao tema, ou a forma que coloquei está legal?
Só não entendi por que está se preocupando em criar gerenciador. Deixe mais claro qual tipo de aplicação está usando e o por quê deste gerenciador. Numa aplicação web, depois que a requisição for enviada para o servidor, o processo será realizado mesmo se o usuário perder a conexão. Lógico que deverá tratar a questão de usabilidade, para o usuário saber o que aconteceu depois, com operações assíncronas isso fica mais fácil.
A aplicação é um projeto para a área da saúde, e para manter os dados do sistema, dependo de alguns arquivos que o governo disponibiliza, então precisarei importa-los em alguns momentos, e um deles possui 5 Gb de tamanho e um outro 2 Gb, fora eles, algumas tabelas do sistema também podem receber dados via importação (o que será mais comum), e dependendo do arquivo que estiver sendo importado, eu não preciso prender a utilização do sistema, então quero que uma thread separada faça esse processo, e o usuário tenha de imediato uma resposta de que a importação foi iniciada, e caso ele queira, poderá abrir a janela de monitoramento e com a barra de progresso. Caso ele não queira, a importação seguirá normalmente, mas quando ela finalizar (por erro ou não), a Thread da importação fica viva por algum tempo (configurável), e caso o tempo seja atingido, o gerenciador a mata. Além disso, caso alguma thread fique parada por algum motivo, ou esteja consumindo muito recurso, um administrador com maior acesso, pode entrar na tela desse gerenciador e matar a thread problemática, além de poder visualizar quais processos estão sendo executados pelos usuários.