У меня был бы какой-то компонент, который всегда работал (например, фоновая служба).
Регулярно тяните ссылки на объекты из-за истечения срока их действия в течение определенного периода времени, имея в виду, чтохотя срок действия объекта может быть в секундах / минутах, вы можете извлекать данные менее регулярно, чем это (скажем, каждые 5 минут, 20 минут, час).Это будет зависеть от минимального времени, в течение которого объект может жить (время между созданием и истечением срока действия).
На данный момент это звучит как 48 часов, так что вы можете извлекать данные каждые 48 часов, но обработкаменьшие объемы данных более регулярно звучат лучше ИМО.Внутренне это будут постоянно истекающие объекты - наверное, каждую секунду, и если команда истечения будет выполняться асинхронно, вам не нужно будет беспокоиться (столько) о завершении предыдущего пакета, прежде чем начнется следующий.
Этот компонент ничего не делает, кроме как извлекает данные и координирует срок действия.Я предполагаю, что фактический акт истечения был бы сделан в другом месте;так что этот компонент будет либо выдавать команды (слишком болтливый?), либо выдавать пакетную команду (а не «пакетное задание», а просто список объектов, срок действия которых истекает сейчас?).
Другой подход заключается в том, чтобы сказать, чтослужба логически является частью основного приложения, даже если она физически отделена (в изолированной службе), что позволяет ей выполнять фактическое истечение срока действия.
Внутренне служба истечения может хранить рабочий список в памяти;когда объект «истекает», убедитесь, что вы выполнили это в транзакции, что обновило бы какой-нибудь аудит / журнал.Если служба умрет, вы узнаете, что было обработано.
Когда служба вернется к работе, она выберет следующий диапазон объектов, включая те, которые не были должным образом обработаны в прошлый раз.для специальной обработки, если необходимо.
Если вы не можете создать службу, вам нужно найти что-то, что запускается так же часто, как вам нужно удалять объекты.