O que sugiro é uma aplicação tal qual é hoje os Applications Servers do Java (Não do mesmo porte). Trabalhando c/ EJB3, vc tem a gerencia da conexão, do pool, da sessão e de um monte de outras coisas no Application Server, e não na sua aplicação.
Este não seia exatamente a sua aplicação, e sim uma segunda aplicação que faria um meio de campo entre a sua aplicação e o servidor web, por isso uma aplicação genérica que poderia ser usada em vários projetos, dai poderia ter um protocolo próprio entre o módulo e sua aplicação. sobre a atualização, o que normalmente se atualiza seria a sua aplicação. O módulo poderia fazer uma cópia de sua aplicação e executa-la de outro lugar, permitindo a substituição da aplicação e o término de uma requisição corrente durante a atualização. A atualização do módulo gerenciador sim, exigiria a parada do servidor, mas, seria da mesma forma que a atualização dum módulo do apache qualquer(incluindo o PHP quando utilizado o módulo do apache ao invez de CGI) faria, o que seria muito mais raro que a sua real aplicação. Já pensei sobre isso a muito tempo, mas como não somos senhores do próprio tempo, eu cheguei a codificar uma parte, como prova de conceito, usando Apache e Delphi, rodando somente sobre Windows e comunicando sua aplicação c/ o módulo atravez de mensagens do windows. Isso já tem alguns anos, mas, com o tempo (Mais especificamente a falta dele) o projeto foi sendo deixado pra traz e hoje nem sei se tenho mais os fontes. Usei na época pra comunicação entre as aplicações um artigo muito bom, mas não o encontrei mais. Mas a idéia é basicamente esta do artigo do link. http://delphi.about.com/od/windowsshellapi/a/wm_copydata.htm?nl=1 Abs Daniel Augusto Bastos 2009/11/11 Marcos Douglas <m...@delfire.net> > Olá Daniel, > > 2009/11/10 Daniel Augusto Bastos <danbas...@gmail.com> > > As sessões do PHP, como nosso amigo Marcos falou anteriormente são por > meio > > de arquivos mesmo. Apesar de ter alternativas(Vide APC), este é o > > comportamento padrão. > > > > O grande lance do PHP é que, usando sessoes, e, incluindo um objeto em > > sessão, o php serializa este objeto pra vc de modo transparente. > > Tem razão Daniel, existem alternativas, mas acredito que 95% dos sites > utilizam a sessão default, que é por arquivo. > > > > O caso do módulo gerenciador que eu falei antes seria justamente pra > deixar > > transparente sessões(preferencialmente em mem). Apesar de não ter pensado > na > > viabilidade disso, mas, este podia manter em memória objetos serializados > da > > sua aplicação independente da requisição, além de poder ela gerenciar o > > Pool. > > Teria realmente a necessidade de parar um servidor em caso de > atualização, > > mas, este não seria um caso frequente, pois, poderia ser um gerenciador > > genérico para várias aplicações. > > > > No mais, esta poderia ter 2 "sabores". ISAPI e módulo do Apache, mantendo > o > > servidor transparente. > > Este módulo tem que ter uma inteligencia de separar objetos para cada > usuário, pois seria uma mesma aplicação compartilhada por várias > requisições de usuários diferentes. Teria muito mais performance, com > certeza. O problema é parar o servidor a cada atualização. Isso seria > um retrocesso considerando o modelo atual, por exemplo o .NET, na > minha opinião. > Não entendi como seria este gerenciador genérico. Se o módulo é apenas > um gerenciador, o que este módulo "chama"? CGI's? > Acho que se o SO for Windows, a melhor opção seria ISAPI considerando > o fato que vc mesmo disse que não há mais problemas com a atualização. > No entanto, acho válido codificar em FPC, pois a aplicação rodaria em > qq SO que o FPC dê suporte. > > > Marcos Douglas > > > ------------------------------------ > > -- > <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> > > > > [As partes desta mensagem que não continham texto foram removidas]
