Как написать резервный механизм, который сохраняет объекты, которые не были успешно сохранены в первый раз

Question

Я пытаюсь написать механизм, который будет управлять моей операцией сохранения в БД.

Я отправляю серверу список объектов, он перебирает их и сохраняет каждый из них.

Теперь,если они терпят неудачу по какой-то странной причине (исключение), они сохраняют их в другом списке, который имеет таймер, который запускается каждые 5 секунд, и пытается их повторно сохранить.

У меня возникает проблема с блокировкой, которую я могу решить с помощью другого логического значения.

Моя функция, которая сохраняет потерянный объект:

private void saveLostDeals() {
    synchronized (unsavedDeals) {
        if (unsavedDeals.size() > 0) {
            for (DealBean unsavedDeal : unsavedDeals) {
                boolean successfullySaved = reportDeal(unsavedDeal,false);
                if (successfullySaved) {
                    unsavedDeals.remove(unsavedDeal);
                }
            }
        }
    }
}

И мой reportDeal()метод, который вызывается для регулярных отчетов и отчета о потерянных сделках:

try {
    ...
    } catch (HibernateException e) {
       ...if (fallback)
     synchronized (unsavedDeals) {
            unsavedDeals.add(deal);
        }
        session.getTransaction().rollback();

    } finally {
       ....
    }

Теперь, когда потерянная сделка сохраняется - если возникает исключение - синхронизированный блок остановит его.

Что вы можете сказать об этом механизме сохранения?Есть ли лучшие шаблоны проектирования для решения этой распространенной проблемы?

Answer 1

Это зависит

Например,

Запрос на сохранение объекта ---> Возникло исключение ---> Проблема с подключением к БД ----> В блоке исключений Повторите попытку сохранения объекта в резервной БД -----> Вернуть ответ на запрос

Запрос на сохранение объекта ---> Возникла исключительная ситуация ---> Проблема с подключением к БД ----> В блоке исключений повторите попытку сохранения объекта в хранилище приложения в памяти -----> Возврат ответа на запрос

Запрос на сохранение сущности ----> Исключение возникает ----> неизвестно исключение ----> В блоке исключений сохранить сущность в хранилище файлов XML [сериализовать в XML] ----> Вернуть ответ с упоминанием temp сохраненные будут обновлены позже на запрос

Таймер ----> проверяет хранилище файлов на наличие сериализованного XML ----> обновляет БД

Очки, за которыми нужно следить

1. Асинхронные вызовы лучше в таких сценариях, чем заставлять клиента ждать.
2. В случае сохранения в памяти следите за количеством данных, сохраненных в памяти, в случае длительного сбоя БД. Это может повредить все приложение
3. Транзакции, хотите ли вы откат сохранить свое прерывистое состояние.
4. согласованность данных для отслеживания

Answer 2

Я бы предложил использовать proxy или aspects для управления механизмом отката / повтора.Прокси-сервер может использовать что-то вроде шаблона strategy для получения рекомендаций о том, какие действия предпринять.

Если вы, однако, не хотите повторить попытку немедленно, а, скажем, через 5 секунд, как вы предлагаете, я бы рассмотрел возможность встроить это в контракт уровня вашей базы данных, предоставив для начала асинхронные процедуры.Что-то вроде dao.scheduleStore(o); или dao.asyncStore(o);.