Как мне запланировать регулярные задачи очистки базы данных в Classic ASP?

У меня есть классический ASP-сайт, который требует, чтобы некоторые таблицы базы данных были очищены от данных сеанса по расписанию. Эта система не имеет доступа к запланированным задачам (она находится на общем веб-хосте и использует сервер MySQL)

Я подумывал об использовании global.asaдля запуска событий как таковых:

  1. Application_OnStart - удалить все данные сеанса из базы данных
  2. Application_OnEnd - удалить все данные сеанса
  3. Session_OnStart - создать сеанс пользователя
  4. Session_OnEnd - удалить все данные сеанса, относящиеся к этому сеансу.

Есть ли причина, по которой я не должен создавать подключения к базе данных global.asa? Они будут созданы и уничтожены здесь, без общего доступа к сеансу или области приложения. Я рассматриваю это как способ запуска этих административных задач дважды для каждого пользователя (в начале и в конце сеанса) и их повторного запуска, что эквивалентно очень небольшому трафику базы данных.

У кого-нибудь есть идеи относительно того, почему это может быть плохо? Какие-либо причины не подключаться к базе данных в global.asa?

Если кто-то думает, что приведенная выше идея является плохой - у вас есть какие-либо другие мысли о том, как я могу регулярно очищать эти таблицы без одного или нескольких из:

  1. Запланированное задание
  2. База данных запланированного задания
  3. Запуск кода при загрузке страницы для каждой страницы (отсюда и Session_OnStartхуки)

Ta»

Старший Кокос

10.11.2009 13:00:32
4 ОТВЕТА
РЕШЕНИЕ

Я бы сделал очистку для одного сеанса Session_OnEndи для всех сеансов в Application_OnStart. Если ваша очистка всех сессий происходит медленно, вы можете сделать некрасивую вещь и поместить эту очистку в отдельный asp-файл, который вы отправляете через http-запрос с использованием класса XMLHTTP, не забудьте дождаться его завершения, так как он не будет обслуживаться до Application_OnStartзапуска всего кода .

2
10.11.2009 15:23:13

Это зависит от того, сколько времени займут ваши задачи по очистке. Поскольку ни один запрос не будет обработан во время работы Application_Start, он может временно блокироваться.

Более того, у вас нет гарантии, что Application_End (или Session_End) будет вызываться во всех случаях (когда сервер выключен, он может не срабатывать, или какой-то катастрофический сбой может полностью обойти эти события).

Как вы предлагаете, лучше всего запустить запланированное задание, отвечающее за очистку устаревших данных сеанса.

3
10.11.2009 15:17:26
Привет Янн, Хороший вопрос: Application_Start замедляет процесс - я бы этого не учел - хотя и не уверен, каковы потенциальные задержки - надеюсь, будет коротким. Я хотел бы надеяться, что session_end удалит большую часть данных сеанса, ограничив любые задержки в Application_Start до минимума (т. Е. Этих запросов должно быть немного, если не произойдет сбой сервера)
Senior Coconut 10.11.2009 15:15:49

Вы можете написать веб-страницу, которая очищает таблицы сеансов, и вызывать эту страницу из внешнего блока с помощью запланированной задачи.

3
10.11.2009 13:17:22
Это то, что мы уже настроили - однако мне не нравится зависимость от другого блока для очистки данных сеанса, и я хотел сделать его «автономным» решением.
Senior Coconut 10.11.2009 15:11:24

Если у вас постоянный трафик, вы можете выполнить небольшие задачи в конце цикла запроса. Просто введите response.flush и затем выполните запросы к базе данных. Конечно, вам нужно написать свой собственный планировщик. Другой вариант - создать отдельный файл asp (тасклет), который вы пингуете с помощью серверной части, async, xmlhttpreq в начале запроса. Это удерживает код очистки от цикла запросов клиентов и уменьшает задержку.

На самом деле, я не удивлюсь, если еще не найдется какой-нибудь умный webappr / api, основанный на appengine, который мог бы пинговать ваши устаревшие тасклеты / webhooks по расписанию. А если нет, вы могли бы написать один сам, варианты бесконечны :)

0
10.11.2009 23:47:40