Pergunta

Eu tenho um site ASP clássico, que exige que algumas tabelas de banco de dados sejam esvaziadas dos dados da sessão em um cronograma. Este sistema não tem acesso a tarefas agendadas (está em um host compartilhado e usando o MySQL Server)

Eu estava pensando em usar global.asa, para disparar eventos como tal:

  1. Application_OnStart - Exclua todos os dados da sessão do banco de dados
  2. Application_OnEnd - Exclua todos os dados da sessão
  3. Session_OnStart - Crie uma sessão de usuário
  4. Session_OnEnd - Exclua todos os dados da sessão relacionados a esta sessão.

Existe alguma razão pela qual eu não devo criar conexões de banco de dados em global.asa? Estes serão criados e destruídos aqui, não compartilhados no escopo da sessão ou aplicativo. Eu vejo isso como uma maneira de executar essas tarefas de administrador duas vezes por usuário (no início e no final da sessão) e não ser disparado novamente para elas, equivalem a muito pouco tráfego de banco de dados.

Alguém tem alguma idéia de por que isso pode ser ruim? Quaisquer motivos para não se conectar a um banco de dados em global.asa?

Se alguém pensa que a ideia acima é ruim - você tem outros pensamentos sobre como posso esvaziar regularmente essas tabelas sem uma ou mais de:

  1. Tarefa agendada
  2. Tarefa agendada para o banco de dados
  3. Executando o código na página Carregar para cada página (daí o Session_OnStart ganchos)

Ta '

Coco sênior

Foi útil?

Solução

Eu faria limpeza para uma única sessão em Session_OnEnd E para todas as sessões em Application_OnStart. Se a sua limpeza de todas as sessões for lenta, você pode fazer uma coisa feia e colocar essa limpeza em um arquivo ASP separado que você faz uma solicitação http para usar a classe XMLHTTP, lembre-se de não esperar a solicitação concluída à medida que ela não começará a ser servido antes de todo o código em Application_OnStart é executado.

Outras dicas

Você pode escrever uma página da Web que esvazia as tabelas de sessão e ligue para essa página de uma caixa externa por meio de uma tarefa agendada.

Depende de quanto tempo levará suas tarefas de limpeza. Como nenhuma solicitação será servida enquanto o Application_Start estiver em execução, ele pode bloquear por um tempo.

Além disso, você não tem garantia de que o Application_end (ou session_end) seja chamado em todos os casos (quando o servidor for desligado, ele não pode ser disparado ou alguma falha catastrófica pode ignorar completamente esses eventos).

A melhor maneira seria, como você sugere, para executar uma tarefa programada encarregada de limpar dados de sessão obsoleta.

Se você tiver tráfego consistente, pode pegar pequenas tarefas no final de um ciclo de solicitação. Basta emitir uma resposta.flush e, em seguida, executar as consultas do banco de dados. Claro que você precisa escrever seu próprio agendador. Outra opção é criar um arquivo ASP separado (Tasklet) que você ping usando um servidor, async, xmlHttPreq no início da solicitação. Isso mantém o código de limpeza fora do ciclo de solicitação de clientes e reduz a latência.

Na verdade, eu não ficaria surpreso se ainda não houver uma WebAppr/API inteligente baseada em AppEngine que possa ping seu legado Tasklet/Webhooks dentro do cronograma. E se não houver, você pode escrever um eu, as opções são infinitas :)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top