|
|
|
Как реализовать transaction log c чтением в обратном порядке?
|
|||
|---|---|---|---|
|
#18+
Для программы типа workflow engine. Есть ациклический dataflow граф, растущий во аремя исполнения. Узлы принимают и отправляют сообщения друг другу. У каждого узла несколько входов. Когда на каждом входе будет по сообщению, запускается задача, которая в процессе своего исполнения посылает сообщения другим узлам. Узлы одноразовые. Логирование необходимо, чтобы при перезапуске не повторять весь счет с самого начала. Восстановление счета надо сделать с точностью до задачи, то есть внутри задачи никаких контрольных точек не предусмотрено. Надо протоколировать: - помещение задачи в очередь исполнения - посылку сообщения задачей - факт завершение задачи Требования : - работает асинхронно, минимально загружая процессор и подсистему ввода-вывода. Сама исполнительная система не ждет окончания записи на диск очередного события. Из-за этого придется повторять некоторые совершившиеся, но не запротоколированные события, но это не страшно, главное - сохранить целостность, чтобы результат был одинаковый как с перезапуском, так и без него. - удлинение файла происходит большими кусками, а не на каждую запись, чтобы не тратить время на обновление метаданных файла - чтение производится в обратном порядке - первым читается сообщение, записанное последним. Сообщения могут быть длинными и при сбоях могут быть записаны не до конца. Проблема найти последнее валидное сообщение в хвосте файла, чтобы начать с него восстановление. Нужна идея, или готовая библиотека, желательно на Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2012, 14:20 |
|
||
|
Как реализовать transaction log c чтением в обратном порядке?
|
|||
|---|---|---|---|
|
#18+
Посмотри, как в Ruote сделано ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2012, 12:45 |
|
||
|
Как реализовать transaction log c чтением в обратном порядке?
|
|||
|---|---|---|---|
|
#18+
rfqДля программы типа workflow engine. Есть ациклический dataflow граф, растущий во аремя исполнения. Узлы принимают и отправляют сообщения друг другу. У каждого узла несколько входов. Когда на каждом входе будет по сообщению, запускается задача, которая в процессе своего исполнения посылает сообщения другим узлам. Узлы одноразовые. Логирование необходимо, чтобы при перезапуске не повторять весь счет с самого начала. Восстановление счета надо сделать с точностью до задачи, то есть внутри задачи никаких контрольных точек не предусмотрено. Надо протоколировать: - помещение задачи в очередь исполнения - посылку сообщения задачей - факт завершение задачи Требования : - работает асинхронно, минимально загружая процессор и подсистему ввода-вывода. Сама исполнительная система не ждет окончания записи на диск очередного события. Из-за этого придется повторять некоторые совершившиеся, но не запротоколированные события, но это не страшно, главное - сохранить целостность, чтобы результат был одинаковый как с перезапуском, так и без него. - удлинение файла происходит большими кусками, а не на каждую запись, чтобы не тратить время на обновление метаданных файла - чтение производится в обратном порядке - первым читается сообщение, записанное последним. Сообщения могут быть длинными и при сбоях могут быть записаны не до конца. Проблема найти последнее валидное сообщение в хвосте файла, чтобы начать с него восстановление. Нужна идея, или готовая библиотека, желательно на Java. почитайте, как работает система с сообщениями (message-oriented middleware) она может восстанавливаться после сбоя там транзакции есть, как в СУБД, есть persistent / non-persistent сообщения и т.д. и т.п. двухфазные транзакции есть для синхронизации с внешними ресурсами вот например WMQ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2012, 21:12 |
|
||
|
|

start [/forum/topic.php?fid=16&fpage=64&tid=1342105]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
615ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
171ms |
get tp. blocked users: |
2ms |
| others: | 205ms |
| total: | 1020ms |

| 0 / 0 |
