Форма JSF для сущности - Горячее редактирование?

Question

Я пишу форму JSF 2.0 для редактирования объекта JPA @Entity.У меня есть компонент поддержки, который имеет метод get для Entity, который он получает из EntityManager.Пока все хорошо.

Вопрос в том, доступен ли объект Entity, редактируемый пользователем, другим частям приложения?Другими словами, если кто-то еще вызывает эту запись, видят ли они изменения поля перед тем, как я объединю запись с базой данных через EntityManager?Или они получают другой экземпляр.

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

Если это общий случай, как мне избежатьпроблема?

Answer 1

Вопрос в том, получает ли доступ к редактируемому пользователем объекту Entity другие части приложения?Другими словами, если кто-то еще вызывает эту запись, видят ли они изменения поля перед тем, как я объединю запись с базой данных через EntityManager?Или они получают другой экземпляр.

Экземпляр объекта, используемый JSF, будет экземпляром отдельного объекта.Это не тот, который принадлежит постоянному контексту.Каждый клиент / пользователь также получит свой собственный экземпляр отсоединенного объекта.

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

Объединение любых недействительных данных произойдет при вызове EntityManager.mergeобъединить содержимое отдельного объекта с постоянным контекстом.Если вы никогда не вызывали merge, то измененное содержимое сущности никогда не попадет в контекст постоянства.

Если это обычный случай, как мне избежать этой проблемы?

Этого всегда можно избежать, проверив состояние объекта перед тем, как объединить его с контекстом постоянства.Чтобы предотвратить этот сценарий, вы можете использовать проверку бинов как в JSF, так и в JPA, хотя обычно вы делаете это только на одном уровне, чтобы предотвратить избыточные проверки.Однако, если вы указали группы проверки для ограничений проверки компонентов, чтобы различать ограничения представления и постоянства, то вы должны использовать проверку компонентов на обоих уровнях.Имейте в виду, что после успешного слияния содержимого компонента с контекстом постоянства вы не сможете многое сделать, чтобы отменить это изменение, за исключением отката транзакции или refresh / clearконтекста постоянства.

Answer 2

Добавление к правильному ответу Vineet:

Возможно, вы получили бы присоединенный объект, возвращаемый вашим компонентом поддержки, например, если вы использовали компонент EJB с сохранением состояния с расширенным контекстом персистентности.

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

Кроме того, JSF не будет вносить изменения в модель (в данном случае это присоединенная сущность JPA), если произойдет какая-либо ошибка проверки. Поэтому, если у вас правильно настроена валидация (валидация бина или обычная валидация JSF), не будет риска «испортить» сущность.

Кроме того, обратите внимание, что для присоединенного случая вам не нужно было бы вызывать merge(), поскольку это произойдет автоматически при закрытии контекста, поэтому вместо этого вы «закроете» bean-компонент с состоянием.

Тем не менее, общий случай - это тот случай, когда Vineet описывает, где вы получаете отдельную сущность.