[firebase-br] Firebird com JSF utilizando pool de conexões e JDBC

[Gladiston Santana]

comentando...

Em dom, 18 de ago de 2019 às 20:49, Reginaldo Martins Costa <
rmc1701e em gmail.com> escreveu:

> Olá Gladiston!
>
> Desculpe a demora (estava em viagem).
>
> O *Classic *se conecta, acessa o banco e libera a memória, confere?
>
>
> O classic mantêm daemons (processos) rodando em memória e aguardando uma
conexão.
Pode haver um numero finito desses processos apenas esperando uma conexão e
quando novos são necessários então eles são criados e somem após a
desconexão, mas o numero minimo configurado deve se manter.
Isso consome mais memória porque eles são independentes, em contrapartida,
ambientes que rodam processos em grade conforme sua configuração podem
escalo-los em CPUs diferentes conforme a demanda.


> O *SuperServer *sobe um processo que fica o tempo todo na memória. Ao
> conectar, esse processo cia uma thread, acessa o banco e libera a thread,
> confere?
>
Sim,. mas as threads tem de acompanhar o processo.
Elas não escalam em grade a menos que o programa tenha sido desenvolvido
para isso, de fato, só podem escalar no mesmo hardware.
Escalar em grade significa que há um programa por cima desses processos
(vamos chamar de monitor) que podem enviar o processo para uma região nova
da grade podendo ser um hardware diferente. Pode inclusive observar a
"pulsação" de um programa e determinar que ele deve dormir ou escalar mais
recursos.
No ambiente Unix, windows e unices como Linux trabalham com thread de
maneira diferente, no Windows por exemplo, uma thread não é independente do
processo, no Linux uma thread pode ter seu próprio PID e inclusive podemos
observar uma thread quando terminiou mas o processo principal ainda não
liberou, da-se-a o nome de zumbi não ocupa tempo de CPU, mas é mal visto
porque parece ocupar recursos que deveriam voltar ao sistema.
Há uma discussão entre engenheiros da computação que o modelo Intel de
lidar desse modo com processos é bem mais otimizado para a computação
pessoal, mas é menos eficiente energicamente.

>
>
> Nesse caso, o Super não seria mais interessante em uma arquitetura web em
> que, o browser faz uma requisição ao servidor, este pega a conexão, faz o
> que tem que ser feito e libera a conexão?
>
>
> A vista grossa sim, mas quando lidamos com processos, se um daemon
quebrar, o sistema levanta outro, se algo tiver levando muito tempo você
pode queimar um daemon, além disso, você pode ver em tempo real esses
processos e tirar deles o tempo de CPU, Disco e Rede que cada um. Isso não
tem valor para quem programa, mas é muito valorizado por um sysadmin. Cada
daemon também pode ter threads então a resposta é que o modelo de processos
pode ser muito mais superior para a web, mas come mais memória que um
modelo tradicional como o SS.


> Última dúvida: qual a diferença desses dois para o *SuperClassic*?
>

Há uma documentação farta na web sobre isso, inclusive no site do Cantu.
Eu lido com bancos diferentes desde tenra idade e algumas coisas que apuz
aqui pode ou não ser aplicável ao FB, então as vezes é melhor tirar o que
falei de artigo bem mais especificos.

Um abraço.