Допустим, есть некая последовательность выполнения методов
Object Class.method1();
Object Class.method2();
Object Class.method3();
Object Class.method4();
Каждый из методов может возвращать набор достаточно "сырых" данных(файлы, collection) достаточно приличным объемом.
Есть задача, если по каким либо причинам при выполнении одного из методов программа "упала", после запуска программы была возможность начать работу с упавшего метода.
Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
самое просто решение это вести лог выполения и кэшировать на hdd полученные данные.
После сбоя искать лог не завершенный и пытаться поднять кэш.
Очевидные проблемы с невозможностью порой сериализовать "чужие" сущности и тд...вообщем давайте обсудим)
On 18/12/11 23:16, cudu wrote:
> Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
Spring Batch
> самое просто решение это вести лог выполения и кэшировать на hdd полученные данные.
Не самое простое решение
Posted via RSDN NNTP Server 2.1 beta
Здравствуйте, mazurkin, Вы писали:
M>On 18/12/11 23:16, cudu wrote:
>> Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
M>Spring Batch
>> самое просто решение это вести лог выполения и кэшировать на hdd полученные данные.
M>Не самое простое решение
как обыдено
C>Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
А разве MessageQ это не оно? В них все эти механизмы "после запуска программы начала работы с упавшего метода" встроены вроде
Здравствуйте, Аноним, Вы писали:
C>>Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
А>А разве MessageQ это не оно? В них все эти механизмы "после запуска программы начала работы с упавшего метода" встроены вроде
Вы у меня спрашиваете? Я не знаю, знал бы — не спрашивал
Здравствуйте, cudu, Вы писали:
C>Допустим, есть некая последовательность выполнения методов
C>Object Class.method1();
C>Object Class.method2();
C>Object Class.method3();
C>Object Class.method4();
C>Каждый из методов может возвращать набор достаточно "сырых" данных(файлы, collection) достаточно приличным объемом.
C>Есть задача, если по каким либо причинам при выполнении одного из методов программа "упала", после запуска программы была возможность начать работу с упавшего метода.
C>Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
C>самое просто решение это вести лог выполения и кэшировать на hdd полученные данные.
C>После сбоя искать лог не завершенный и пытаться поднять кэш.
C>Очевидные проблемы с невозможностью порой сериализовать "чужие" сущности и тд...вообщем давайте обсудим)
для этого вам придется сохранять в постоянное хранилище (файловая система, DB, ...) весь тот большой объем данных после вызова каждого метода.
Будет ли это оправдано в плане производительности? При небольшой вероятности сбоев может оказаться быстрее пересчитать заново несколько методов.
Здравствуйте, tavr, Вы писали:
T>Здравствуйте, cudu, Вы писали:
C>>Допустим, есть некая последовательность выполнения методов
C>>Object Class.method1();
C>>Object Class.method2();
C>>Object Class.method3();
C>>Object Class.method4();
C>>Каждый из методов может возвращать набор достаточно "сырых" данных(файлы, collection) достаточно приличным объемом.
C>>Есть задача, если по каким либо причинам при выполнении одного из методов программа "упала", после запуска программы была возможность начать работу с упавшего метода.
C>>Кто нить красиво это решал в standalone приложениях без всяких haxa транзакций?
C>>самое просто решение это вести лог выполения и кэшировать на hdd полученные данные.
C>>После сбоя искать лог не завершенный и пытаться поднять кэш.
C>>Очевидные проблемы с невозможностью порой сериализовать "чужие" сущности и тд...вообщем давайте обсудим)
T>для этого вам придется сохранять в постоянное хранилище (файловая система, DB, ...) весь тот большой объем данных после вызова каждого метода.
T>Будет ли это оправдано в плане производительности? При небольшой вероятности сбоев может оказаться быстрее пересчитать заново несколько методов.
данные приходят от стороннего сервиса и на 1 get система может потратить час времени.
При условии, что мы не хотим разбираться: это сетевые проблемы, либо стороннего сервиса, требуется таки данные пока что кэшировать и после сбоя поднимать.
Самый простой метод использовать ehCache с кэширование на диск с валидным временем кэша , допустим 2 часа.
Но вдруг кто то красивеее решал? Проблема еще в том, что требуются сериализованные данные. Что иногда — довольно затратно по времени(я имею ввиду кодирование из за получения чужих сущностей несериализуемых)
Здравствуйте, cudu, Вы писали:
Я сейчас похожие проблемы решаю.
Есть последовательность действий. Каждое действие использует результат предыдущего. Например, такая цепочка:
1. Поток биржевых торговых сообщений реального времени преобразуется в 1-минутные интервалы.
2. 1-минутные интервалы преобразуются в 5,10,... минутные интервалы.
3. На основании минутных интервалов вычисляются статистики.
4. Статистики с положительным результатом отсылаются потребителям.
Соответственно, у меня 4 приложения. Каждое приложение является одновременно Производителем и Потребителем. Сбой означает перезапуск соответствующего приложения.
Все приложения работают по одной схеме:
1. Вычисленный результат записывается в файл и отсылается подсоединенным потребителям. Файл является также и логом.
2. При подсоединении нового потребителя ему отсылается сначала содержимое файла (история производителя), а потом новые ресультаты (обновления) по мере их вычисления.
3. При рестарте приложение сначала читает содержимое файла (свою историю производителя), чтобы знать с какой точки производить. Затем подключается как потребитель к внешнему производителю и получает его историю и поток обновлений.
Я пробовал реализовать это на распределенной памяти. В частности, экспериментировал с Hazelcast, который меня привлек своей простотой. Но по ряду причин оставил. Сейчас использую прямые сокетные соединения.
Что касается сериализации, то
http://terracotta.org/ сообщала, что обьекты в их распределенной памяти не обязаны быть сериализуемы, т.е. они их сами, очевидно, модифицируют. Но я не вникал.
