JEE 7 JSR 352 передает данные из пакета в шаг фрагмента

Я прочитал стандарт (и javadoc), но у меня все еще есть некоторые вопросы. Мой вариант использования прост: пакет извлекает данные из внешнего источника и подтверждает данные (это означает, что данные удаляются из внешнего источника после подтверждения). Перед подтверждением данных пакет создает соответствующие выходные данные (in-menory-object), которые должны быть переданы на следующий шаг, ориентированный на порции.

Вопросы:

1) Каков наилучший способ передачи данных между пакетом и этапом фрагмента? Кажется, я могу сделать это, вызвав jobContext#setTransientUserData в пакете, а затем на шаге своего фрагмента я могу получить доступ к этим данным, вызвав jobContext#getTransientUserData.

Я понимаю, что и jobContext, и stepContext реализованы в режиме threadlocal. Что меня здесь беспокоит, так это часть "Transient". Что произойдет, если батчлет завершится успешно, а мой чанк-шаг завершится ошибкой? Будут ли данные «TransientUserData» по-прежнему доступны или они исчезнут, если задание/шаг будет перезапущено? Для моего варианта использования важно, чтобы пакет запускался только один раз. Таким образом, даже если задание или шаг чанка перезапущены, важно, чтобы выходные данные успешно запущенного пакетного релиза были сохранены, в противном случае пакетный релиз должен быть создан еще раз. (Я уже подтвердил данные, и они исчезли, поэтому повторный запуск пакета мне не поможет.)

2) Дополнительный вопрос. В stepContext есть несколько методов: getPersistentUserData и setPersistentUserData. Каково предполагаемое использование этого метода? К чему относится «Постоянная» часть? Эти методы актуальны только для разбиения?

Благодарю вас! / Даниэль


person xdaiv    schedule 10.03.2018    source источник


Ответы (1)


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

Пошаговые постоянные пользовательские данные — это данные приложения, которые разработчики пакетных заданий считают необходимым сохранить/сохранить для целей перезапуска, мониторинга или аудита. Они будут доступны при перезапуске, но обычно они относятся к текущему шагу (а не к шагам).

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

person cheng    schedule 11.03.2018
comment
+1 Спасибо за ответы на мои вопросы. Еще один дополнительный вопрос (возможно, больше к разработчикам стандартов): по какой причине не предоставляется get/setPersistentUserData в JobContext? - person xdaiv; 11.03.2018
comment
Я не помню веских причин против этого, и идея была поднята. Я думаю, что это просто не было приоритетом, который попал в окончательный релиз. Еще один способ: на шаге 2 вы можете получить постоянные пользовательские данные с шага 1, сначала получив StepExecution от JobOperator.getStepExecutions(); ... , а затем StepExecution.getPersistentUserData() (по крайней мере, для потока верхнего уровня). - person Scott Kurz; 11.03.2018
comment
На самом деле, я видел подобное решение (JobOperator.getStepExecutions(); ...), но мне оно не показалось лучшей практикой. Не могли бы вы уточнить свой комментарий (по крайней мере, для ветки верхнего уровня)? Будет ли это решение потокобезопасным во всех ситуациях (не только в потоке верхнего уровня)? - person xdaiv; 11.03.2018
comment
Я имел в виду, что пользовательские данные, полученные из контекста шага, являются локальными для потока, поэтому каждая партиция получает свою собственную, как и поток верхнего уровня, но через JobOperator API доступны только данные StepExecution верхнего уровня и пользовательские данные. (Это также было упомянуто как идея улучшения спецификации, которая еще не стала приоритетной). - person Scott Kurz; 12.03.2018